jschultzpedersen

Hi Yes, that seems like a good idea to use sockets. I also saw an article in one of the old Millers Graphic magazines, (issue June 1984) that mentioned that it was the mid 244, that was particularly prone to go bad - on the flex cable card, that is. But maybe the same goes for the P-card.

Hi After some experimentation with the good and the bad P-code card I think I need to try replacing the 244 and 245 chips. By the way - thanks for pointing out I had missed the 245 chip. I only looked for LS codes. With the working card I tested as follows...with the Mini Memory cartridge installed. Turn the P-card on and boot. Then Halt to get back to the Ti99 boot menu to select Easybug, Then use EasyBug to... Check G1F00 - it reports 01. Then set it to 01 - light turns on. Then check M4000 - it displays AA. So it sees the ROM. Then check G1F00 again - it displays 01. Set it to 00 - light goes off. Then check M4000 - value is now 00 (Which I presume means there is nothing there/cannot see ROM. All in all I assume this is the expected behaviour, and that it works. With the bad card nothing happens. The computer never reach the boot screen or flashes the P-code card light. Awk! I have not soldered since the early nineties. I wonder if my gear still works?! Fortunately, it seems the chips are easy to get and very cheap. So there is room for errors. :-)

Hi I did a little exploring. 🙂 'Shotgunning' is also used for a certain way of opening and drinking a can of beer. On a more serious note. I have included a picture of the print. If I understand this correctly I should replace the three SN74LS244N chips near the connector (and cross my fingers as there is no obvious damage the the print anywhere, that I can see. The serial no is: 9021 LTA3082). There do not seem to be any 74LS245 chips on the board. When I boot the system, lights go on for assorted cards in the PEB, such as the 32 K RAM, disk controller card, the disk drive, the RS232 and the P-code card too. Some are steady and some are flashing. After several seconds all but the RS232 eventually turns off and that is it. I never get the first of several beeps signalling that the p-card is taking over, and the screen remains blank. Everything works as normal with my working P-code card.

Hi Ahh... My english/american vocabulary was just extended. Thanks! regards Jesper

Hi Thanks for the info. I will acquire a 74LS245 and a 74SL244 and see if I get lucky. Just to be sure as I am not familiar with the phrase... 'shotgunning' means replacing ? regards Jesper

Hi Some years ago when I had my interest in the TI99 rekindled, I bought a P-Code card with Pascal manual and software on Ebay. Unfortunately I had issues with my PEB at the time, and it took several months to get a working PEB. Then I discovered the P-Code card was a dud. It turned the light on, when booted, but never went further in the boot process. I remember reading somewhere, that a specific batch of cards from TI had that problem - something to do with a diode, that was supposedly easily fixed. The card is of a type, that have no switch to force P-code card boot or a regular boot. Apart from not working it seems to be in excellent condition. I do have another card that works now. But it would be a shame to ditch the card, if it can be fixed. There aren't many out there judging by the lack of offers on Ebay. Does someone know of a fix - assuming it is the diode thing or another typical issue, that I haven't heard about? regards Jesper

It sounds just right with such a distance. My current Leaf can do about 400 km at this time of year. I 'upgraded' it from my original Leaf, that I bought nearly nine years ago. That car could only do about 150 on a fully charged battery, which was as good as it gets then, but is rather limiting even in a small country like Denmark by current standards. The nice thing is that I run on solar power from my roof cells for most of the year. So driving it is dirt cheap! I would love to do a one-day visit to see your 'slightly enhanced' setup. It would have to be a Saturday or Sunday. Just name a date.... You can write me at jesper@chessspot.dk. If you could find time to visit me, I have a fairly basic TI99 setup with a PEB with 2 disk drives, 32 K and serial port. But perhaps I can tempt with my collection of old home computers of the same age as the TI99 :-)

Lets see. If I get this right Traryd is located about a 100 km from the ferry between Denmark and Sweden, so it is well within the range of my electric car, even for a return trip. I lived for some years in Gothenburg back in the nineties. So I should be able to handle myself on the swedish roads. The same goes for a trip the other way if you care to visit me in my village close to Hillerød. I have a small confession - I do not drink alcohol. So schnapps is not an option for me. But do not let that stop others 🙂 In any case, it should be fun to meet a 'live' TI99 user.

The TI99 was fairly big in Denmark too for a while. I started out buying a TI99 i 1982 - the first computer the shop sold to a customer. It did not take long before I was employed in the shop, running the computer sales dept. We sold hundreds of TI99, and we were probably the last place in Denmark, where you could buy TI99 games and equipment, since we bought all the stuff Texas had in storage, when they closed down. But eventually the C64 killed it off completely. Back then there was little software and information about the system was hard to get. Things have changed... Now I can get answers to all the questions I had then, and there are free software and hardware extensions, that goes beyond my wildest dreams then. Is anyone aware of any active TI99 clubs in Denmark or Sweden? The TIUKUG (UK user group) has a small one day gathering on the 30. of Sept. near Leicester, but it is kind of too far away for me to contemplate. Any arrangements in Denmark or the southern parts of Sweden would suit me better, as they are within driving range.

Team Nordic - that sounds good! I believe there was a good number of ti99 fans in Sweden earlier, judging by the 'Programbiten magazine' that flourished in the early nineties. I have downloaded most of them, and they kind of inspired me to write some articles for the TI*MES magazine - the TIUGUK user clubs bi-annual magazine. I find that writing articles for others is an excellent way to teach myself about a subject. And who knows... It might tempt others to dig out that old TI99 like I did and have some fun.

Yes, I just realised I was not the only TI99 user around here. So I put the country on the profile 🙂 regards Jesper

Hi Yes, my project with doing pseudo HIRES graphics in Extended Basic was because I was curious about the capabilities of regular Extended Basic. There are superior extensions like The Missing Link out there, and I have downloaded them, but I was trying to see, what I could do with 'straight' Extended Basic. Anyway, that was last year. This year I have spent my time on working with Forth, and lately I have turned to assembler. it is nice to be back after a break of 35 years! 🙂 regards Jesper

Hi I wrote an article for the TI*MES magazine, vol.2 no. 20. June 2023,that is relevant to this discussion. The article discussed using Extended Basic - compiled, of course - to plot graphics, and supplied code for plotting pixels, lines and circles etc. In case you do not know it... The TI*MES magazine is a magazine, issued twice per year, from the TIUGUK user group. The code supplied here is a partial extract of that article. It demonstrates the basic task of redefining character patterns continuously - like it is done in LOGO II. I have also included the code for drawing circles and how to do clipping. sub setclip(ymin,xmin,ymax,xmax,clip()) if ymin<1 or ymin=0 then ymin=1 else if ymin>192 then ymin=192 if xmin<1 or xmin=0 then xmin=1 else if xmin>256 then xmin=256 if ymax>192 or ymax=0 then ymax=192 else if ymax<1 then ymax=1 if xmax>256 or xmax=0 then xmax=256 else if xmax<1 then xmax=1 if xmin>xmax then tmp=xmax :: xmax=xmin :: xmin=tmp if ymin>ymax then tmp=ymax :: ymax=ymin :: ymin=tmp clip(1)=ymin :: clip(2)=xmin :: clip(3)=ymax :: clip(4)=xmax subend sub plotpix(x,y,ch,clip()) if x<clip(1) or y<clip(2) or x>clip(3) or y>clip(4) then subexit hx$="0123456789ABCDEF" fx=int((x-1)/8)+1 :: fy=24-int((y-1)/8) px=x-8*fx+8 :: py=1-y+8*(25-fy) hex=px-int(px/4)*4 :: hex=hex-(hex=0)*4 :: hex=2^(4-hex) call gchar(fy,fx,chc) :: call charpat(chc,ch$) if chc=32 then chc=ch :: ch=ch+1 :: call char(chc,"0") c=2*(py-1)+2+(px<5) :: tmp$=seg$(ch$,c,1) :: tmp=(pos(hx$,tmp$,1)-1) or hex nch$=seg$(ch$,1,c-1)&seg$(hx$,tmp+1,1)&seg$(ch$,c+1,16-c) call char(chc,nch$) :: call hchar(fy,fx,chc) subend Drawing circles or parts of circles normally depend on the use of trig functions like SIN and COS. They are available in Extended Basic, but they are not supported by the compiler, because it only works with integers. Drawing entire circles can still be done easily with the equation x^2 + y^2 = r^2. But drawing parts of a circle is hard without the trig functions. This routine therefore always draws an entire circle. I should add that the manual for the compiler has an example of how to add your own SIN tables to a program. So, it can be done. sub circle(x2,y2,r,ch,clip(),cx,cy) cx=x2 :: cy=y2 d=int(r*7/10) for dy=-d to d dx=int(sqr(abs(r^2-dy^2))) call plotpix(x2+dx,y2+dy,ch,clip()) call plotpix(x2-dx,y2+dy,ch,clip()) next dy for dx=-d to d dy=int(sqr(abs(r^2-dx^2))) call plotpix(x2+dx,y2+dy,ch,clip()) call plotpix(x2+dx,y2-dy,ch,clip()) next dx subend Notice that the center of the circle may lie outside the clipped area (usually the screen area). Only those parts of the circle, that are inside the clipped area, will be drawn. One benefit if this is, that you can draw, say, a half-circle by redefining the clipping area, so the other part is chopped off. Here is an example: SETCLIP(100,0,0,0,ch,clip()) :: CIRCLE(100,100,50,ch,clip(),cx,cy) This code will draw a circle with its center at 100,100 and a radius of 50. But since only pixels larger than XMIN, which is 100, are drawn, we get a half-circle. Of course, being Extended Basic - even compiled - it cannot compete speed wise with solutions in Forth or Assembler. But you do get pseudo HIRES graphics in the bargain - until you run out of ink, that is! regards Jesper

Hi Ok. Less that one hundred instructions per interrupt cycle. No wonder it did not work even if I only scrolled a few characters (In fact that almost works with just two characters). I can see that if I try around 30 characters, it start running at 30 fps instead of 60 fps when using the WI routine to synchronize. That means it takes more than 1/60 of a second to process the scroll. I put a lot of effort into managing everything using registers for optimum speed. I had to use variables for a few counters, as I was running out of registers in the most complex code section (the actual scroll calculations) It paid off, since the execution speed grew from about 50 with my first attempts to eventually about 70 executions per second. It also helped, when I realised that I could process the patterns in 16 bits instead of 8 bits at a time. This saves a lot on SLA instructions though the handling of 'overflowing' bits between patterns gets a little more complicated. I have included a .txt file with the raw code if someone is interested. Notice the last block (number 50). This is where I store the text for scrolling. This is reflected in the stack parameters to the TSETUP word. (Block 50, 100 characters). regards Jesper Scroll code tf.txt

Hi again My scrolling project seems to have hit it highwater mark. I can execute 800 scrolls in about 11 seconds with 27 characters. The ASM code is divided into five words. These words are executed from within a loop in TurboForth. This is faster than 60 times a second, but obviously the computer has other things to attend to besides running my code. So turning the words into one ASM word and executing it via interrupt is not possible for me. The system locks up after the first scroll. The good news is, that it runs fine when synchronized with the WI (wait for VDP interrupt) routine published earlier. 800 loops run in about 13 seconds with a fairly stable movement and only an occasional stutter. This matches 60 updates per second. So I guess I made it! The tricks and tips provided by your comments have helped a lot reaching the final result, which spans 6 blocks. If anyone is interested in the code, I can publish it here. I will probably write a commented version of the code for an article in the TI*MES magazine. But it may take a year before it gets published, since there are 2 issues per year, and I have another article queued up already. My inabillty to run it using interrupt raises a question. How many instructions can you execute in an interrupt routine? I have no problem running words with, say, 15-20 instructions via interrupt. But thousands..... no way near it. regards Jesper