Jump to content

Photo

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


566 replies to this topic

#551 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,638 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 ONLINE  

InsaneMultitasker

    River Patroller

  • 2,082 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,638 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 ONLINE  

InsaneMultitasker

    River Patroller

  • 2,082 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,638 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,638 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   1 downloads

 

-M@



#557 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • 419 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,283 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,253 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 ONLINE  

InsaneMultitasker

    River Patroller

  • 2,082 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,109 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,361 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 ONLINE  

InsaneMultitasker

    River Patroller

  • 2,082 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,361 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,361 posts
  • Location:Portland, Oregon USA

Posted Yesterday, 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,638 posts
  • Location:Beaverton, OR

Posted Yesterday, 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,253 posts
  • Location:Germany

Posted Yesterday, 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






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users