jschultzpedersen

Hi Adding the ability to easily create cartridge modules in XB2.9 G.E.M. is a very nice feature. Thanks! I am now testing the option to create chained cartridges in BX2.9 G.E.M. But it does not work for me. What am I doing wrong here? I have two XB programs like this: Module B is saved as DSK3.MB. It is the compiled and assembled and ends up loaded as DSK3.MB-X. Then it is converted to cartridge format as DSK3.MB-8.BIN. I can then run it as a cartridge using the CARTRIDGE/USER/OPEN option. 100 CALL CLEAR :: CALL SCREEN(11) 110 PRINT "THIS IS MODULE B" 120 CALL KEY(0,K,S):: IF NOT S THEN 120 130 PRINT "END OF MODULE B" 140 END Similarly i create an XB file called DSK3.MA. It ends up as a cartridge file called DSK3.MA-8.BIN. 100 CALL CLEAR :: CALL SCREEN(10) 110 PRINT "THIS IS MODULE A" 120 CALL KEY(0,K,S):: IF NOT S THEN 120 130 PRINT "END OF MODULE A" 140 RUN "DSK3.MB-8" 150 END I then run DSK1.CHAINCARTS... First cart in chain: MA-8.BIN Name on menu: JSP Name of chained cartridge: M-8.BIN It loads cartridge A and B producing a file called DSK3.M-8.BIN of size 64 Kb. When running the combined cartridge, it displays the strings "THIS IS MODULE A" and "END OF MODULE A". But it does not run the next module. I have tried with different file names in the RUN command like DSK3.MB, DSK3.MB-8 and DSK3.MB-8.BIN. But to no avail. I presume it is the file name, that is wrong, but What file name should I use for the setup i described? If I run the programs as pure XB programs (no compilation), it works when using the 140 RUN "DSK3.MB" statement. By the way... In the manual dated 07-23-2023 for the "JUWEL" developer package, the illustrations on page 3 are still referring to the ISABELLA version though the text refers to the "JUWEL" version.

Hi Thanks for the suggestions. I think I will focus on the FinalGrom99 solutions. Time for some reading of manuals ..:-) regards Jesper

Hi Yes, that was exactly what made me wonder about the cartridge version of MG Explorer. I had hoped that this version had some extra commands not mentioned in the manual for the disk version, that allowed me to boot with GM Explorer (cartridge version) and then load a file from disk and analyse it. There was a disk on the Italian website next to the .bin image. It had an E5 type file on a .dsk image with MG Explorer, that I can 'run'. But then - I suppose I need the EA module active. So, no Extended Basic cartridge at the same time... regards Jesper

Hi I just got my hands on a .bin file with MG Explorer, as well as a copy of the manual (for the disk version). I can load the .bin file via my FinalGrom99 and see and work in the Explorer on my TI99. But how do I use the Explorer, if I have, say an Extended Basic program, which requires the Extended basic Cartridge activated? In the manual the Explorer is loaded from disk with CALL INIT :: CALL LOAD("DSK1.XBEXP"). But, as I have a cartridge version of Explorer available, I presume I have to activate the Explorer in some other way. But how?... regards Jesper

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

Hi I used the code supplied by TheBF to wait for VDP Interrupt as a word in TF ( called WI) before calling my scroll routine as well as as an integral part of the assembler code. This works fine insofar as to give a relatively stable display of the scrolling text 30 times a second. The bad news is, that the scroll routine is too slow to run 60 times a second (It does about 53 / s). So with the synch word as a delay it runs every second VDP interrupt instead. During a walk I had an idea for an alternative algorithm, that should be faster. So the next few day will show if this works out to more than 60 / s. Anyway, the information provided has given me a good idea of how to work with assorted interrupts, Thanks everybody! regards Jesper

Hi again The scroll routine is now wrapped up in a single ASM word. Each call of the word scrolls 1 pixel for the entire visible string and feeds a new character every 8 scrolls. I have hooked it up to the interrupt address at $a008. This too works. However, the scrolling is not completely smooth as I kind of expected. While I have problems getting it to run at 60 frames per second with a full 33 character displayed - it runs at about 53 frames per second - which is not enough to include in an interrupt driven process, I have tested with far fewer characters displayed. But despite running at way more than the required 60 framed, it is still not smooth... if fast. Interestingly it runs smoother if placed in a loop in TF with about 29 characters displayed. I suspect the problem has to do with synchronizing with the screen update. Does this make sense? PS. How do I stop hooking up to the interrupt at $a008? Do I write a RT instruction to the address to replace the vector? The ASM code uses almost all the cpu time. So the machine is rather unresponsive, when it runs. Considering that it has to recalculate around 250 bytes, 60 times a second, I do not blame it. But it means I have to put a condition inside the scroll code to stop. Another thing that confuses me a bit is... I read that I should end my code with an RT or R11 ** b, command. However, it only works for me without such a command. Is my information obsolete, or should it be R12? regards Jesper

Hi again Things are now moving almost at VBL speed with the latest improvements. Somewhere between 55-60 refreshes per second. I can probably get there, if I write the current four ASM modules into one. I took a small MPEG2 video - at least I think it is MPEG2 The camera is at least 15 years old 😀. Besides, I used medium quality, since high quality means a 50 Mb file, which may or may not irritate others. I cannot get the inbuilt video recorder in Classic99 to work. I tried to download the Cinepak Codec for Windows 10, but got warnings about it including a trojan horse by Norton. So I respectfully denied and dug out the old Cybershot camera. Since it only handles 25 frames per second, the scrolling gets a bit chopped up, running at twice that speed. But you get an idea of how it behaves currently. regards Jesper MOV02009.MPG

Hi again I listen and learn.... Thanks! $8C00 CONSTANT VDPW $8C02 CONSTANT VDPA ASM: RAM->VRAM ( VRAM RAM LEN -- ) *SP+ R2 MOV, *SP+ R1 MOV, *SP+ R0 MOV, R0 $4000 AI, R0 SWPB, R0 VDPA @@ MOVB, R0 SWPB, R0 VDPA @@ MOVB, R15 VDPW LI, BEGIN, R1 *+ R15 ** MOVB, R1 *+ R15 ** MOVB, R2 DECT, EQ UNTIL, ;ASM --> VARIABLE MYDATA : TEST HERE MYDATA ! 10 ALLOT 10 0 DO 65 I + I MYDATA @ + C! LOOP 30000 0 DO ( 0 MYDATA @ 10 VMBW ) 0 MYDATA @ 10 RAM->VRAM LOOP ; With your improvements implemented, the RAM->VRAM word is apparently faster than the standard VMBW word. The test program ran at about 15 seconds vs. 19 seconds. Both versions write ten characters from RAM to the top left corner of the display 30000 times. I think I can implement these methods in a couple of other places in my code and hopefully get similar speed increases. If it all works out, I will probably do an article for the TI*MES magazine, published by the English user club. It would be the natural conclusion to some earlier articles I wrote about scrolling in other languages for the TI99. regards Jesper

Hi again I am trying to push the speed of my scroll routine to make it less than 1 VBL in duration. I am not quite there. But it made me think... I tried to make my own version of VMBW using the TurboForth workspace. My routine works like this: $8C00 CONSTANT VDPW $8C02 CONSTANT VDPA ASM: RAM->VRAM ( VRAM RAM LEN -- ) *SP+ R2 MOV, *SP+ R1 MOV, *SP+ R0 MOV, R0 $4000 AI, R0 SWPB, R0 VDPA @@ MOVB, R0 SWPB, R0 VDPA @@ MOVB, BEGIN, R1 ** R7 MOV, R7 VDPW @@ MOVB, R7 SWPB, R7 VDPW @@ MOVB, R1 INCT, R2 DEC, EQ UNTIL, ;ASM I assume the code behind VMBW is similar, if not exactly the same. And yet, my code runs about 30% slower. Is this because the TurboForth code is in 16 bit ROM space while my code is in 8 bit RAM, or is my code just inefficient? If the cause is the 16 vs. 8 bit code location, I will not spend more time trying to 'outrun' the TurboForth code 😀 regards Jesper

Hi Aha. I was thinking of using ASM to generate the MC code, since either method seems to generate the same MC code, and then get the hex codes for CODE via the DUMP utility. But this is easier. Thanks. And don't worry - I have no intentions of learning all the codes for the 10 different formats used by MC code. 😃 I just wanted to understand the 'inner workings' of how instructions are implemented. If there is no advantage to using CODE, I'll probably stick with ASM. Using CODE may save some bytes in the source code if not in the compiled code, but three months from now I would probably have forgotten what the hex code was supposed to do and how, unless I commented it lavishly. And once I have used BSAVE / BLOAD to store the actual MC code, the question of whether CODE or ASM compiles faster, means nothing. regards Jesper