+jedimatt42 Posted June 23, 2018 Author Share Posted June 23, 2018 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/jedimatt42/tipi/blob/master/hardware/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@ 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 23, 2018 Share Posted June 23, 2018 So, I need to understand what is wrong with this assembly code: https://github.com/jedimatt42/tipi/blob/master/hardware/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.. 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 23, 2018 Author Share Posted June 23, 2018 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@ 3 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 23, 2018 Share Posted June 23, 2018 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 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 23, 2018 Author Share Posted June 23, 2018 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@ 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 23, 2018 Author Share Posted June 23, 2018 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 ) -M@ 4 Quote Link to comment Share on other sites More sharing options...
+9640News Posted June 23, 2018 Share Posted June 23, 2018 Great news and great detective work solving the issue. Looks like I will be ordering two after all!!!! Beery 2 Quote Link to comment Share on other sites More sharing options...
Shift838 Posted June 23, 2018 Share Posted June 23, 2018 count me in for a couple too! Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 23, 2018 Share Posted June 23, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 23, 2018 Share Posted June 23, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 24, 2018 Share Posted June 24, 2018 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.... 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 24, 2018 Share Posted June 24, 2018 lol. These days who knows 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 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 24, 2018 Share Posted June 24, 2018 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. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 24, 2018 Share Posted June 24, 2018 Sort of would like dsk emu to work too tho Sent from my LG-H872 using Tapatalk Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 24, 2018 Share Posted June 24, 2018 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 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 24, 2018 Author Share Posted June 24, 2018 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@ Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 24, 2018 Share Posted June 24, 2018 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. genbench.dsk 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 25, 2018 Share Posted June 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 25, 2018 Author Share Posted June 25, 2018 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@ Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted July 1, 2018 Share Posted July 1, 2018 Btw WiFi works fine in the pbox Sent from my LG-H872 using Tapatalk 4 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted July 1, 2018 Author Share Posted July 1, 2018 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@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted July 21, 2018 Author Share Posted July 21, 2018 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@ 1 Quote Link to comment Share on other sites More sharing options...
Sinphaltimus Posted July 22, 2018 Share Posted July 22, 2018 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? Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted July 22, 2018 Author Share Posted July 22, 2018 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/jedimatt42/tipi/wiki/Design#cru-addressing -M@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted July 22, 2018 Author Share Posted July 22, 2018 and here: https://www.ninerpedia.org/wiki/Communications_Register_Unit -M@ 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.