jjh76 Posted May 29, 2018 Share Posted May 29, 2018 Don't know if this had been reported yet, but 64 column mode in telnet displays random characters under the cursor 2 Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 29, 2018 Share Posted May 29, 2018 On the progress side, I was able to get the TIPI-PEB version working Friday, and then the last issue fixed today. There are 2 issues with the pcb design, both fairly easily worked around. Woot! -M@ Great progress. Curiosity here with a question. Will the TIPI-PEB design allow the TIPI to be mounted on the card in the PEB, then it being just a matter to supply the extra cabling to the TIPI? I'm assuming this will take up 2 (3??) slots due to the extra width if you are going that route? Beery Beery Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted May 29, 2018 Share Posted May 29, 2018 Yes but you give up access to it and possibly a second peb slot. Also WiFi could be problematic from inside the box. Sent from my LG-H872 using Tapatalk Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 29, 2018 Author Share Posted May 29, 2018 Don't know if this had been reported yet, but 64 column mode in telnet displays random characters under the cursor I'll add it to my issues list.. Thanks! -M@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 29, 2018 Author Share Posted May 29, 2018 Great progress. Curiosity here with a question. Will the TIPI-PEB design allow the TIPI to be mounted on the card in the PEB, then it being just a matter to supply the extra cabling to the TIPI? I'm assuming this will take up 2 (3??) slots due to the extra width if you are going that route? Beery Beery http://atariage.com/forums/topic/265136-tipi-ti-994a-to-raspberry-pi-interface-development/?p=4013120 -M@ Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 29, 2018 Share Posted May 29, 2018 Thanks for the link to the image. Are the "Ref" holes on the board for securing the Raspberry PI? One thing I saw was the orientation of the LED. Maybe I am missing something, but I would have thought you would have wanted to rotate the legs 90 degrees so they would bend in an L shape to face the LED panel without touching. Maybe you have something else in mind not obvious to me. Just thought I would comment. Beery 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 29, 2018 Author Share Posted May 29, 2018 Yep, the LED mistake slipped by... This was a rendering... The holes do indeed line up for a PI 3. I still have to stop at the hardware store and find some nylon to test mount it with. Here are real pictures of the first board. I do have a few changes to make: Fits in the PEB well: I think you can see I bent my LED creatively... I thought I read that SCLK/AMD is LOW on a 4A, but I read 2.5 volts which confused my 74'138, where I have it attached with a pull-down resister to enable the decoding. That finally answers the question I asked months ago about why the genmod decoding jumpered. For the prototype, I just cut the trace and let the pull-down do its job. The signal strength from the CPLD isn't good enough to get to the PI 3... Worked fine with a PI Zero attached right to the back, but the extra struggle of getting through the transmission wires was too much... so I added a 10k ohm pull-up on the single data-to-PI line (r_din). That worked like a charm. --- So, 2 alterations are required before we start selling these... I'm a little ahead of my self though... I have to build a couple more manually altered instances to be tested in ElectricLab and Arcadeshoppers machines. --- My first reaction to getting it working this weekend was: I'm done. I've achieved stage 2 of my goal. But I'll carry on and get this built for everyone to enjoy. ( Oh and to make my life easier, I need to annotate all over the silk screen layer... KiCad decided SMD parts don't need to have their values printed... cause good reasons, like the density is usually such that there is no pcb space for it. ) --- Oh, and now I have the ultimate case for my TIPI ( A PEB, in case that wasn't obvious ) -M@ 11 Quote Link to comment Share on other sites More sharing options...
Shift838 Posted May 29, 2018 Share Posted May 29, 2018 Great progress Matt! Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted May 30, 2018 Share Posted May 30, 2018 Awesome work and I can't wait! Sent from my LG-H872 using Tapatalk Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 30, 2018 Share Posted May 30, 2018 I can't wait either. Will be ordering two, one for the Geneve and one for the TI system. Beery 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 30, 2018 Share Posted May 30, 2018 Matt, I've asked this before and you pointed me towards a direction with some C code. I'm more assembly, than C, so hopefully you can point/create an example piece of code. When the PEBox version of TIPI comes out, I am hoping to be able alter some existing RS232 code for the MDOS terminal program My-Term to use it. I know you have mentioned there are some ports for transferring characters. If you could show an example in assembly (TI-99/4A source is fine) where you turn on the card, execute any code for a telnet session, and to then be able to send/receive characters through ports however it is done, it would be appreciated, Is it possible to have an overflow on the port if you are not scanning often enough? At this point, I am trying to understand what is or is not possible. Obviously, a lot is possible, I just do not have a suitable code base I can easily follow the logic. Anyways, food for thought if you get the time. Thanks. Beery 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 2, 2018 Share Posted June 2, 2018 I've managed to find a way to lock up the TIPI a time or two. Is there a way to install a reset button so you dont have to connect via cellphone to make people Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 2, 2018 Author Share Posted June 2, 2018 Omega, The design is that going to the TI title screen signals with a dedicated line, that the services on the PI are restarted. My current implementation of that is occasionally unresponsive, as I signal a watchdog process that then instructs the primary process to exit. I have been testing an improvement where when signaled, the watchdog does not ask, it instead forces the termination and relaunch of the primary service process. This should fix it. If you want a PI reset button, there are many solutions out there on the internet. But after I release the next update, if anyone still has this issue, I ask that you report it, so that it can be addressed, and the community doesn't suffer. Workarounds are to software usability, how you kill a frog by acclimating it to boiling water. -M@ Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 2, 2018 Author Share Posted June 2, 2018 Beery, Eventually, yes, I will create a TCP example is assembly. The PI buffers the socket. And TCP does all of its glorious things so there isn't data loss. All the handshakey and flow controlly issues are handled by linux. On the TI, you send a block of data, or you request to read a block into a buffer. You will get at most your buffer size back. If you get less than your buffer size, then there is no more data ready. The wiki has something describing the TCP messaging protocol. The TI-Artist mouse driver shows how to message TIPI in assembly. Including how to discover the crubase. The actual messaging send and receive routines are in the TIPI ROM, tipi-io.a99 -M@ Quote Link to comment Share on other sites More sharing options...
+9640News Posted June 2, 2018 Share Posted June 2, 2018 Beery, Eventually, yes, I will create a TCP example is assembly. The PI buffers the socket. And TCP does all of its glorious things so there isn't data loss. All the handshakey and flow controlly issues are handled by linux. On the TI, you send a block of data, or you request to read a block into a buffer. You will get at most your buffer size back. If you get less than your buffer size, then there is no more data ready. The wiki has something describing the TCP messaging protocol. The TI-Artist mouse driver shows how to message TIPI in assembly. Including how to discover the crubase. The actual messaging send and receive routines are in the TIPI ROM, tipi-io.a99 -M@ Thanks for the information. When I get some free time, I will explore it. I've marked this page to come back to it later. Beery Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 2, 2018 Share Posted June 2, 2018 Omega, The design is that going to the TI title screen signals with a dedicated line, that the services on the PI are restarted. My current implementation of that is occasionally unresponsive, as I signal a watchdog process that then instructs the primary process to exit. Okay. In this example shown below, I'm bypassing the title screen, which could be an issue. This only occurs when I'm using 4A/DOS with the autobooting cartridge and the disk version of PALEA5. Sometimes it locks up the TIPI forcing me to reset it by the cellphone or PC, sometimes not, it's weird. I does screw up the screen at least once though. https://www.youtube.com/watch?v=nzkpRFBL4sg&feature=youtu.be 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 3, 2018 Author Share Posted June 3, 2018 Okay. In this example shown below, I'm bypassing the title screen, which could be an issue. This only occurs when I'm using 4A/DOS with the autobooting cartridge and the disk version of PALEA5. Sometimes it locks up the TIPI forcing me to reset it by the cellphone or PC, sometimes not, it's weird. I does screw up the screen at least once though. https://www.youtube.com/watch?v=nzkpRFBL4sg&feature=youtu.be So my guess is the TI crashes while in the middle of an IO call to the TIPI. I think that is what I have a fix for. But I have to ask, what is PALEA5? What is the expected behavior? You aren't complaining that PALEA5 crashes, so I'm guessing you don't expect it to work. Is that right? -M@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 3, 2018 Author Share Posted June 3, 2018 If what is bypassing the title screen doesn't allow peripheral powerup routines to run, then yes, maybe that is a part of it. -M@ 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 3, 2018 Share Posted June 3, 2018 So my guess is the TI crashes while in the middle of an IO call to the TIPI. I think that is what I have a fix for. But I have to ask, what is PALEA5? What is the expected behavior? You aren't complaining that PALEA5 crashes, so I'm guessing you don't expect it to work. Is that right? -M@ PALEA5 is a program written by Rasmus for users of the F18A. What it does is enhances the contrast (especially in text mode) of the display. Basically all it does is changes some display settings and then reboots the computer. Of course once the computer is rebooted, my auto-booting cartridge takes over. I think it might all be a little bit too fast for the old TI to handle. I have to add PALEA5 works without a hitch in every other scenario, whether it be in DSK format or FlashROM image. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 3, 2018 Author Share Posted June 3, 2018 PALEA5 is a program written by Rasmus for users of the F18A. What it does is enhances the contrast (especially in text mode) of the display. Basically all it does is changes some display settings and then reboots the computer. Of course once the computer is rebooted, my auto-booting cartridge takes over. I think it might all be a little bit too fast for the old TI to handle. I have to add PALEA5 works without a hitch in every other scenario, whether it be in DSK format or FlashROM image. Ok, PALEA5 alone, works fine when loaded from TIPI. ( Opinion - Ick... funny story: Someone brought a TI monitor to the meetup last weekend, and was frustrated that the colors looked kind of like these, instead of our fresh looking F18A and Classic99 matching colors... sorry, I'm just a retro newb that doesn't really remember what a CRT looks like ) Anyway... this might be a completely different problem than what I suspected. Probably more of an issue with your fast boot trying to load data before the tipi service has restarted. I don't actually wait for it in the power up routine... cause that would be complicated, and hasn't seemed necessary... most of the time if the service is down, IO routines just block on the TI side until the service starts and responds. Maybe you can point me at what is run when your console reboots? -M@ Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 3, 2018 Author Share Posted June 3, 2018 Also, I assume you have tried removing your cartridge and resetting the TI console before resorting to rebooting the PI? If not, next time it hangs on you, try that. It might re-enforce some theories. THanks! -M@ Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 3, 2018 Share Posted June 3, 2018 Maybe you can point me at what is run when your console reboots? -M@ Sure. In << THIS MESSAGE >> you'll find all the information and even source code on what is happening. Essentially the routines in the 1284P bypass the menu, and immediately load 4A/DOS from the 49F040... and to make things quicker, it even loads CHARA1 off the 1284P. This sucker fast, maybe too fast, but I love it! I'm super happy with it. In fact I had to add an extra batch file just to keep it from freaking out with the sound when it tried to load a large batch file immediately. Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 3, 2018 Share Posted June 3, 2018 (edited) Also, I assume you have tried removing your cartridge and resetting the TI console before resorting to rebooting the PI? If not, next time it hangs on you, try that. It might re-enforce some theories. Will do, but yeah, I tried everything, removed the cartridge, reset (multiple times), even unplugged power from the TIPI/32K. Nohting worked, except the remote reset. -- edit -- Oh yeah, I even cycled power on the TI itself. Edited June 3, 2018 by --- Ω --- Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 3, 2018 Share Posted June 3, 2018 FYI: This is the source code of the PALEA5 program. It just sets up the palette and then quits. VDPWD EQU >8C00 * VDP write data VDPWA EQU >8C02 * VDP set read/write address START LIMI 0 LWPI WRKSP * F18A Unlock LI R0,>391C * VR1/57, value 00011100 BL @VWTR * Write once BL @VWTR * Write twice, unlock LI R0,>01E0 * VR1, value 11100000, a real sane setting BL @VWTR * Write reg * Load color paletttes LI R0,>2FC1 * Reg 47, DPM = 1, AUTO INC = 1, start PR1 BL @VWTR * Every two bytes written to the VDP now go to the palette registers. LI R0,PAL LI R2,30 * Each 12-bit palette entry requires 2 bytes UPDPAL MOVB *R0+,@VDPWD DEC R2 JNE UPDPAL LI R0,>2F00 * Reg 47, exit DMP BL @VWTR * F18A Lock LI R0,>391C * VR1/57, value 00011100 BL @VWTR * Write once * Return BLWP @>0000 ********************************************************************* * * VDP Write To Register * * R0 MSB VDP register to write to * R0 LSB Value to write * VWTR SWPB R0 MOVB R0,@VDPWA * Send low byte (value) to write to VDP register SWPB R0 ORI R0,>8000 * Set up a VDP register write operation (10) MOVB R0,@VDPWA * Send high byte (address) of VDP register B *R11 *// VWTR ********************************************************************* * * Palette PAL DATA >0000,>00B0,>00F0 DATA >0008,>000F,>0700,>00FF DATA >0C00,>0F00,>0BB0,>0FF0 DATA >0060,>0C0B,>0CCC,>0FFF * Workspace WRKSP BSS 32 END START 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 3, 2018 Author Share Posted June 3, 2018 Thanks, I don't believe there is anything about PALEA5 that is at issue. I suspect it is just the attempt to load a 4ADOS script before the tipi.service has rrstarted. I suspect that the load starts then the service gets terminated in the middle, and we're hung. I don't have an ubergrom to test with... We'll see what I can do to reduce the race condition window. -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.