Hans23

The reason for the placement is that the joystick and mouse ports are connected to the keyboard controller. The underside of the keyboard seems to be the only viable place where the connectors can be put and made accessible from the outside. I guess it saved a few dollars in the BOM for the machine not having to put a separate I/O chip onto the main board, but rather use one microcontroller for all user input devices.

I've ordered 10 PCB's and will give it a try. I'll let y'all know whether I get anywhere with it. -Hans

The firmware ZIP file contains the .MCS file with the FPGA bitstream. I'm not actually intending to change the VHDL at this point, just building and using an F18A would be alright for me. Any experience reports would be appreciated. -Hans

Hey, does anyone have experience with building an F18A from the design files at CircuitMaker? The soldering job seems doable, but is this the latest version and will it run with the firmware published on Matthew's site? Thanks, Hans

Nice comment style! I'll try to use that. One thing about names in TurboForth is that they seem to be restricted to 15 characters in length, and it seems to not take it well when one tries to define a word with a long name: This caused me quite some head scratching before I realized that the limit exists. Anyway, there are some habits from the modern world that don't carry over well when going back to a small system like the TI-99/4A. Thank you again for your comment (style)!

Hi Lee, thank you for looking at my code! I had considered working with the data stack more, but the issue that I really have is that I then have one more value on the stack that I need to keep track of in my head in order to understand the code. I don't know if this is difficult for me because I am not used to it or if it is and just stays difficult, being the price of the simplicity of Forth. It also seems to me that my words are just too long, and making them generally smaller would make sense. What keeps me from trying to go that way is that I also find it hard to invent meaningful names, and my intuition is to keep that namespace clean. I guess that this is one of the things I need to overcome Anyway, thanks again! Any further hints, or maybe pointers to good source code to study, would be appreciated. Cheers, Hans

Hi, I am struggling with doing things the Forth way, maybe someone here can help me out or point me to an material that'd help. I'm attempting to write a game in TurboForth. It will be a two person game where the objective of each player is to reach the base of the other player. Consider it to be a programming exercise more than the attempt at a good game, as it is my first. Anyway, here is what it looks like right now: The vertical walls with the moving gates are updated every few frames, and the code that does it looks like this: $A6 value gate-char 22 value wall-height variable gates 3 cells allot variable gate-width 5 gate-width ! variable gate-speed 10 gate-speed ! : update-gate ( n -- ) >r [email protected] 1 and if [email protected] [email protected] dup [email protected] gate-x swap gotoxy gate-char emit dup gate-width @ + wall-height mod [email protected] gate-x swap gotoxy space 1+ else [email protected] [email protected] dup [email protected] gate-x swap gotoxy space dup gate-width @ + wall-height mod [email protected] gate-x swap gotoxy gate-char emit 1- then wall-height mod [email protected] gate! r> drop ; : update-gates ( -- ) 4 0 do i update-gate loop ; The word that concerns me is obviously UPDATE-GATE, which moves the gate in one of the walls up or down, depending on whether its index is even or odd - I find it really hard to understand what the code does. By using the return stack to hold the gate number, things get a little easier, yet there still is a lot of stack value juggling that one needs to follow. Also, the code duplication between the up and down movement of the gate concerns me, but how could those two branches be combined into one parameterized word that, in itself, does not need to deal with many opaque stack parameters? I'm seeing it as a reoccuring issue when I write words that need to deal with multiple associated values, like the X and Y coordinate of one or multiple objects. Many of the operations involved are very simple, but the required mechanics to access values on the stack get complicated and confusing quickly. Any help or pointers would be much appreciated! Thank you, Hans

Thank you all for the deep dive! It is very educative

I could not resist and built a little test rig for the 373 to figure out what is wrong with it. It seems that the chip lets data pass through even if latch enable is low. On a working 373, the behavior for latching data looks like this (green D, yellow Q, blue LE, red OE): Data appears on the output pin when after LE goes high, all fine. On the failing chip, I see this: Here, the output follows the input even though LE is low. This was a fun little exploration and I think I can safely say that this is a broken 74LS373N Cheers, Hans

Lee, this looks quite appropriate, thanks!

This is useful, thanks!

That's true, but it seems that there is something reproducible about the fault. The screen image always looks very similar, albeit not the same. I have decided that I'm intrigued enough to try testing the 373 with an Arduino based program. I'll report whatever I find, even though it will be completely useless as this fault will not likely happen again, ever

What I'm really after is a real-time counter. I had, not knowing a lot about the TI-99/4A, assumed that the vertical blanking event would be a good way to get a 50/60Hz interrupt source. From what I read, it seems that with TurboForth, it would be best to rely on the LIMI 2 LIMI 0 sequence for handling the interrupts, and make sure that one of the words that has this sequence is called often enough. I would think that installing a user-defined ISR handler in the USRISR hook would be the appropriate place to interface to the "polled interrupts" scheme. Does that make sense? Is vertical blanking the only interrupt source, or are there any other interrupts that could cause the USRISR to be invoked? Sorry for the naive questions, I'm still new to the TI-99/4A and to Forth and I appreciate your patience!

Without the latch, the machine runs the internal Basic just fine. With a cartridge inserted, I get the "INSERT CARTRIDGE" message. It seems that the 373 is somewhat doing its thing (which is also confirmed by the IC tester reporting that it is working). I would think that this is a very rare failure mode, but it may be worth noting that if the 373 completely fails, the machine starts without a cartridge but displays "INSERT CARTRIDGE" when a cartridge is inserted. I'm keeping the 373 in my dead parts bin, maybe I'll test it some more with a specialized test rig if I'm running out of other things to do

I had some unexpected behavior when calling WI and COINC in a loop - Sometimes, things seem to work fine, but if I changed the invocation order in the loop, COINC failed to detect overlaps. It seems like TurboForth is somehow dealing with interrupts, after all: ; COINC ( tolerance spr1 spr2 -- flag ) _coinc mov @bank1_,@retbnk ; return to bank 1 if taking interrupt limi 2 ; let interrupts run limi 0 mov *stack+,r2 ; get spr2 mov *stack+,r1 ; get spr1 movb @>837b,r0 ; get vdp status register (ed/as pg. 405) andi r0,>2000 ; check collision bits jeq miss ; if NO sprites are in collision then ; don't do the rest of the test. If I understand correctly, the LIMI 2/LIMI 0 sequence unmasks interrupts for the duration of one instruction, is that correct? Does this cause queued (VDP) interrupts to be processed? In that case, would WI interfere in clearing the VDP status word, which would then make COINC not detect the overlap? I dug a little deeper into the TurboForth code and there seems to be an interrupt service routine. I guess this would be a good place to hook in to, which would also allow me to maintain an incrementing frame counter. Thank you for your help! -Hans

Thanks, @TheBF @Tursi @Lee Stewart! This gives me a bunch of things to experiment with, which is what I'm going to do

Sounds like fun. Parts and postage to and from Germany would be on you, though.

I was amazed myself, but I am rather sure: I installed sockets on the three bus transceiver/latches and I could go back to the faulty behavior by putting the origin 373 back in.

I don't think I even want to try to compete. Repairing stuff is the fun to me

I have found the issue: The 74LS373 in the 8/16 bit data bus converter was faulty. Interestingly enough, it tested as OK in the TL866+, so it seems that the chip must somehow become marginal. Now I have too many TI-99/4A's Thanks for reading! Hans

As the problem was reproducible with both cartridge port riser cards and consistent between the two, I did not think that this was the problem. To make extra sure and to have a look at this felt thing, I've now removed it and cleaned the port once more, but it did not help with the issue. Thanks anyway, I'll leave the felt thing out now - It indeed looks dirty and not very trustworthy.

I only have two cartridges, a FinalGROM99 and a ROM-only cartridge with TurboForth. The problem occurs with both. The picture I sent above is what I get from the ROM-only cartridge. With FinalGROM, I get the two expected menu entries, but the machine crashes when I select 2 (FinalGROM99).

Just because it was relatively easy to do, I've also exchanged the 138 address decoder that generates the chip select for the cartridge port, the two SRAM chips and the system ROMs. This did not change anything. 😕

@Schmitzi Thank you for the suggestion! I've just tried it again, using DeoxIT D5 on the edge connector of the PCB for cleaning and lubrication. I also tried two different raiser cards, both of which worked in the other board. Maybe I will try swapping the edge connector between the non-working and the working board, although both of them look clean.

Hi, I have recently found two TI-99/4As that apparently have been a repair project of someone else who had given up at some point. They attempted swapping around chips and even moved the CPU from one board to the other without any severe damage. I'm now trying to finish the job, but I'm running out of ideas - I'm still a relative noob with the TI-99/4A so maybe someone here has a hint and can help: The faulty machine is starting fine and it runs Basic without apparent problems. When I insert any cartridge, however, it displays the initial startup screen but then fails at the selection. I have exchanged the GROMs, the CPU and the VDP, but none of that helped. Not knowing a lot about the TI-99/4A or TMS9900, it seems to me as if the initialization routine fails to read from the cartridge, but it also seems as if some wrong data is read and then causes the menu code to never detect that there are no more cartridge based programs and eventually overwrites memory that is not supposed to overwrite. Not sure, of course. Any hints or ideas would be greatly appreciated.