Jump to content

Photo

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


715 replies to this topic

#551 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sat Jun 23, 2018 1:32 AM

I pruned out the power up routine. All but the toggle of the PI reset crubit, and the 'only if I'm >1100' vdp stack file buffer setup.

 

Still no luck... I then deleted the DSR list headers for all the DSK* devices.  No difference... 

 

Then, I zeroed out the header link to the powerup routine. And basically it works. In ROMPAGE on my Geneve. 

 

I set the crubase to >1400 so it would be after >1100 cause all I have to boot off of is an old TIFDC ( Which does not work in ROMPAGE mode -- anger, confusion with or without disk emulation on )

 

anyway... now powerup and booting into MDOS is fine... I'm able to setup ROMPAGE, and load the EA cartridge, go into TI BASIC and CALL TIPI to get to TIPICFG and update the stuff using the PI. special files. Load programs from TIPI....  Browse  around in DM2K... DIrectory listings of TIPI. DSK0. and DSK4. work...   

 

My TELNET client works in 40 and 64 column mode. 

Loading from URI3 worked... 

 

Of course, the DSK1-3 emulation doesn't work because the TIFDC is present at a lower crubase.  ( I'm tempted to add a switch so I can turn off the ROM on my floppy controller. --pull CS high to disable it-- ) 

 

Ah, but the Geneve BOOT doesn't look at DSK1 in crubase >1000, (quick to the bat cave) so with the power up routine disabled, I'm able to boot, and DSK1-3 emulation off of TIPI works in ROMPAGE.  I just ran Old Dark Caves from CAVES folder on TIPI mapped as DSK1.  :) 

 

--- 

 

So, I need to understand what is wrong with this assembly code:  https://github.com/j...dsr/powerup.a99

 

I tried removing the goofy shit for the sound list... and that didn't help. It is possible I fumbled that... But I do require that I can detect my crubase, toggle the PI reset line, and set the file buffers. 

 

-M@



#552 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,202 posts

Posted Sat Jun 23, 2018 2:22 AM


 

So, I need to understand what is wrong with this assembly code:  https://github.com/j...dsr/powerup.a99

 

I tried removing the goofy shit for the sound list... and that didn't help. It is possible I fumbled that... But I do require that I can detect my crubase, toggle the PI reset line, and set the file buffers. 

 

-M@

 

hmmm. TIPI is enabling interrupts before the powerup routine returns to the caller.  Comment out the LIMI 2 and try again. If that fixes the problem, investigate why you had turned on interrupts to begin with.  Was it for the sound list processing? If so, I would recommend removing the LIMI 2 from the powerup and testing to see if the sound list still fires.  The powerup scan really shouldn't be interrupted; perhaps the TI ROM shuts off the 9901/9918 interrupts prior to this routine? I'm not in a position to research.

 

The Geneve boot EPROM does not contain an interrupt handler. I suspect the VDP interrupt is firing and never being serviced..



#553 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sat Jun 23, 2018 9:44 AM

Thanks InsaneMultitasker! And thanks for your patience with me.

 

That did it... I left that in on the first attempt because I still had the code writing to the VDP for the buffers... 

 

But then I debugged the 4A boot up code, and think I was unlucky when I decided if I could LIMI2 or not... :)  It looks like it periodically enables the interrupt, and I must have caught it in that state. 

 

Anyway, new code for DSR rom is pushed to master, and works on Geneve and 4A. 

 

I have one more issue on the Geneve, and that is argument parsing in BASIC with my CALL TIPI subroutine.  CALL TIPI works to bring up the default EA5 program which is TIPI.TIPICFG, but CALL TIPI("TIPI.NET.TELNET")  also brings up TIPI.TIPICFG ... I admit my code for this is largely based on evidence under classic99, and not specification.  :( 

 

Since TIPI 99% works on Geneve now, I want to get that last bit worked out before shipping anything. 

 

-M@



#554 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,202 posts

Posted Sat Jun 23, 2018 12:03 PM

In basic.a99 you are moving a word from VDP to R9, to check for parameters. Change to a MOVB and see if that takes care of the issue.

 

; create a PAB

LI R0,VDPPAB ; destination: PAB in VDP

LI R1,PAB  ; source: PAB template in ROM

LI R2,10  ; length: 10 bytes.

BLWP @VMBW  ; copy LOAD pab template to VDP

AI R0,9  ; destination: length byte in VDP PAB

MOV R8,R1  ; source: string parameter to " TIPI" in CALL TIPI...

AI R1,5  ;   check if '(' is present for parameters

.setvdpra R1

CLR R9

MOV @VDPRD,R9

CI R9,>B700 ; compare with string parameter tokens are present

JEQ copyname

; otherwise use default name

LI R1,TIPICFG

LI R2,13

BLWP @VMBW

JMP loadfiles



#555 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sat Jun 23, 2018 1:38 PM

In basic.a99 you are moving a word from VDP to R9, to check for parameters. Change to a MOVB and see if that takes care of the issue.

 

; create a PAB

LI R0,VDPPAB ; destination: PAB in VDP

LI R1,PAB  ; source: PAB template in ROM

LI R2,10  ; length: 10 bytes.

BLWP @VMBW  ; copy LOAD pab template to VDP

AI R0,9  ; destination: length byte in VDP PAB

MOV R8,R1  ; source: string parameter to " TIPI" in CALL TIPI...

AI R1,5  ;   check if '(' is present for parameters

.setvdpra R1

CLR R9

MOV @VDPRD,R9

CI R9,>B700 ; compare with string parameter tokens are present

JEQ copyname

; otherwise use default name

LI R1,TIPICFG

LI R2,13

BLWP @VMBW

JMP loadfiles

 

That did it! It is easy for me to understand that the second byte I copied is from an address with an undefined state in the hardware map... This is actually my first assembly language project since one week in the mid 80s. 

 

I'm not sure how you spot that while multitasking insanely... 

 

Thanks!

-M@



#556 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sat Jun 23, 2018 1:45 PM

I guess all that is left, is to figure out what it will reasonably cost me to make these, and start making them. 

 

Here is a final rendering from KiCad ( in real life, there will be a socket + eprom, and the PI connector will be a shrouded right angle type ( same as regular TIPI )

 

Attached File  Screenshot from 2018-06-22 23-44-25.png   878.1KB   6 downloads

 

-M@



#557 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 578 posts
  • Location:Campbellsburg, KY

Posted Sat Jun 23, 2018 2:44 PM

Great news and great detective work solving the issue.  Looks like I will be ordering two after all!!!!  :) 

 

Beery



#558 Shift838 OFFLINE  

Shift838

    River Patroller

  • 2,412 posts
  • SHIFT838
  • Location:Deer Park, Texas

Posted Sat Jun 23, 2018 3:57 PM

count me in for a couple too!



#559 mizapf ONLINE  

mizapf

    River Patroller

  • 3,356 posts
  • Location:Germany

Posted Sat Jun 23, 2018 4:48 PM

That did it! It is easy for me to understand that the second byte I copied is from an address with an undefined state in the hardware map... This is actually my first assembly language project since one week in the mid 80s.

 

Not sure whether this is important, but one should also keep in mind that the byte order is different between the TI console and other TI processors. The databus multiplexer of the TI console first accessed the odd byte (LSB), then the even byte (MSB), while the TMS9980A and the TMS9995 use a MSB-LSB order. This may have an effect for memory-mapped devices.



#560 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,202 posts

Posted Sat Jun 23, 2018 5:12 PM

I'm not sure how you spot that while multitasking insanely...

lol. These days who knows ;)

 

Congratulations - yet another piece of hardware makes it through the gauntlet.  



#561 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,690 posts
  • Location:워싱턴 주

Posted Sat Jun 23, 2018 6:40 PM

I guess all that is left, is to figure out what it will reasonably cost me to make these, and start making them. 

 

Many people standing by in anticipation ready to order....  :-D

Attached Files



#562 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,586 posts
  • Location:Portland, Oregon USA

Posted Sat Jun 23, 2018 8:11 PM

lol. These days who knows icon_wink.gif

 

Congratulations - yet another piece of hardware makes it through the gauntlet.  

 

well HIS gauntlet.. mine (GENEVE with upgrade ram and hfdc) does not want to load mdos with the TIPI at 1000 cru..   It goes to the hard disk for a quick bit (I assume load/sys) and then hangs on the TIPI.. 

 

At a high cru it loads mdos fine.. 

 

Greg



#563 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,202 posts

Posted Sat Jun 23, 2018 8:33 PM

 

well HIS gauntlet.. mine (GENEVE with upgrade ram and hfdc) does not want to load mdos with the TIPI at 1000 cru..   It goes to the hard disk for a quick bit (I assume load/sys) and then hangs on the TIPI.. 

 

At a high cru it loads mdos fine.. 

 

Greg

Sounds about right for a setup with HFDC.  LOAD/SYS likely is confused by a DSKx device that it does not expect.  Sounds like you already found a solution.



#564 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,586 posts
  • Location:Portland, Oregon USA

Posted Sat Jun 23, 2018 8:34 PM

Sort of would like dsk emu to work too tho

Sent from my LG-H872 using Tapatalk

#565 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,586 posts
  • Location:Portland, Oregon USA

Posted Sun Jun 24, 2018 12:10 AM

further testing on the geneve is necessary.. as it isn't communicating properly in mine i can see the values set by the pi but the geneve is unable to set values at the address of the tipi device.. so it boots up fine but when you access tipi it never gets the messages so lockup 



#566 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sun Jun 24, 2018 1:05 AM

Greg's Geneve in rompage is not able to write to the shift registers in my CPLD mapped to address 5FFD and 5FFF. It is able to read the two at 5FF9 and 5FFB. These are each single byte items.

Maybe a problem in my CPLD code for decoding a write operation. Don't know why it works on mine and not Greg's.

-M@

#567 mizapf ONLINE  

mizapf

    River Patroller

  • 3,356 posts
  • Location:Germany

Posted Sun Jun 24, 2018 11:58 AM

Tim and I tried to find out the meaning of CRU bit 23

INTXT  EQU  1            ENABLE EXTERNAL INT TO 9901=1, NOT ENABLE=0
INTVDP EQU  2            ENABLE VDP INT TO 9901=1, NOT ENABLE=0
INTKB  EQU  8            ENABLE KEY BOARD INT TO 9901=1, NOT ENABLE=0
CPEBRS EQU  16           PE BOX RESET 1=ACTIVE, 0=INACTIVE
C9938  EQU  17           RESET TO AVDP CHIP
KBREST EQU  22           BIT TO RESET EXTERNAL KEYBOARD IF AVAILABLE
XMEMCY EQU  23           EXTERNAL MEM CYCLES 0=LONG, 1=SHORT
VDPWAT EQU  25           VDP WAIT CYCLES 1=ADD 15 CYCLES, 0=ADD NONE

The problem is that I could not find any difference in run time with bit 23 set or unset on my Geneve. The boot EPROM sets the bit to 1 and never touches it again. My test program on the attached image delivers the same values for test #3 and test #4, where test 4 plays with the bit.

 

If you have a Genmod and a way to transfer this program to your computer, it would be interesting to learn whether it has an effect for Genmod. I seem to remember that all PBox accesses for the stock Geneve are 1-ws; the Genmod is designed to have 0-ws. So maybe the stock Geneve overrides the setting of the bit, where Genmod does not.

Attached Files



#568 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,202 posts

Posted Mon Jun 25, 2018 2:23 PM

Greg's Geneve in rompage is not able to write to the shift registers in my CPLD mapped to address 5FFD and 5FFF. It is able to read the two at 5FF9 and 5FFB. These are each single byte items.

Maybe a problem in my CPLD code for decoding a write operation. Don't know why it works on mine and not Greg's.

-M@

 

I wonder if Michaels post #559 holds the key.  Could writes to the odd versus even byte (address) be gumming up the works. Hopefully this is a simple problem to resolve.



#569 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Mon Jun 25, 2018 3:37 PM

 

I wonder if Michaels post #559 holds the key.  Could writes to the odd versus even byte (address) be gumming up the works. Hopefully this is a simple problem to resolve.

 

Maybe... I only map latch bytes into the LSB of a word.. I would think the 9995 more normal in this regard.  The 4A is difficult, in that the ME and WE don't change between bytes, and just the low address line does. 

 

To work around that, I consume the PH3 clock signal and use that to trigger sampling the address and choosing what latch is set to the data bus.  I haven't looked at what timing diagrams might be out there for that.  And I don't remember why I thought this was a good idea... I'd have to go back and look at the 4A timing diagrams. 

 

On my Genmod, I've tried with both positions of the waitstate switch... both work - I'll double test this weekend.   So maybe there is a small change I can make to triggering in the verilog code...  this will require experimentation on a failing Geneve. 

 

What else don't we know about Genmod?

 

-M@



#570 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,586 posts
  • Location:Portland, Oregon USA

Posted Sun Jul 1, 2018 10:02 AM

Btw WiFi works fine in the pbox

Sent from my LG-H872 using Tapatalk

#571 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sun Jul 1, 2018 3:32 PM

Tim and I tried to find out the meaning of CRU bit 23

INTXT  EQU  1            ENABLE EXTERNAL INT TO 9901=1, NOT ENABLE=0
INTVDP EQU  2            ENABLE VDP INT TO 9901=1, NOT ENABLE=0
INTKB  EQU  8            ENABLE KEY BOARD INT TO 9901=1, NOT ENABLE=0
CPEBRS EQU  16           PE BOX RESET 1=ACTIVE, 0=INACTIVE
C9938  EQU  17           RESET TO AVDP CHIP
KBREST EQU  22           BIT TO RESET EXTERNAL KEYBOARD IF AVAILABLE
XMEMCY EQU  23           EXTERNAL MEM CYCLES 0=LONG, 1=SHORT
VDPWAT EQU  25           VDP WAIT CYCLES 1=ADD 15 CYCLES, 0=ADD NONE
The problem is that I could not find any difference in run time with bit 23 set or unset on my Geneve. The boot EPROM sets the bit to 1 and never touches it again. My test program on the attached image delivers the same values for test #3 and test #4, where test 4 plays with the bit.
 
If you have a Genmod and a way to transfer this program to your computer, it would be interesting to learn whether it has an effect for Genmod. I seem to remember that all PBox accesses for the stock Geneve are 1-ws; the Genmod is designed to have 0-ws. So maybe the stock Geneve overrides the setting of the bit, where Genmod does not.

 
I cannot reliably boot my Geneve without the TIMODE switch on. This may skew the numbers... unless you are testing access explicitly to the 'fast' memory. 
 
The results of running 'speed5' in 'turbo' (0-waitstate) mode are:
 

Result for test 01: 175
Result for test 02: 306
Result for test 03: 328
Result for test 04: 328

 
With 'turbo' switched off:
 

Result for test 01: 174
Result for test 02: 305
Result for test 03: 328
Result for test 04: 328


With 'turbo' still off, and I run it again... then I get the same numbers as the first run... 175, 306, 328, 328

rebooting with software command 'timode' removed from AUTOEXEC produces still the same numbers. I was also able today to boot with the TIMODE switch off... and got also the same numbers.

With repeated runs in any mode, the results vary between the first two sets.

-M@

#572 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sat Jul 21, 2018 5:35 PM

Ok, I believe the PEB boards are final enough.

I received 20 pcbs. Wednesday. Built 2 for myself. And all seems well.

I was able to eliminate the system clock signal from my verilog. That was a hack I was happy to see gone.

I'm not doing pre-orders. I will order components to populate the boards Tomorrow, and then as I get inventory built I will let Arcadeshopper put them in-stock. Same for further side port boards.

You might experience some sticker shock, but these are much slower to build and have 3 times the surface area to debug. They eat up my hobby time something horrible. And I still haven't figured out packaging material costs.

Also, like prior cards before me, DSK mapping doesn't work if you have crubase conflicts. That's just the way the TI is. For best results, evict anything using CRUBASE >1000, and let the TIPI have that.

-M@

#573 Sinphaltimus OFFLINE  

Sinphaltimus

    River Patroller

  • 2,514 posts
  • Distracted at the Keyboard
  • Location:Poconos, PA

Posted Sun Jul 22, 2018 4:35 PM

Also, like prior cards before me, DSK mapping doesn't work if you have crubase conflicts. That's just the way the TI is. For best results, evict anything using CRUBASE >1000, and let the TIPI have that.

-M@

 

Is there a reference for what cards are set to what CRUBASE? 



#574 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sun Jul 22, 2018 5:17 PM

 

Is there a reference for what cards are set to what CRUBASE? 

 

I'm collected this information, but I'm sure it is incomplete:

 

https://github.com/j...#cru-addressing

 

-M@



#575 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,800 posts
  • Location:Beaverton, OR

Posted Sun Jul 22, 2018 5:22 PM

and here: https://www.ninerped...s_Register_Unit

 

-M@






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users