kl99

It's Fabrice Montupet and the TI(ny) 99/4A project you refer to. He did it solely for himself. People asked if they can have one of these once he did go public about it, but that was not his intention. He achieved to analyze the 99/4A down to the last resistor and recreated the schematics based on his findings which revealed a few errors in the schematics we know. To be honest I am not interested in money. Nor do I feel capable of realizing such a project on my own. Even if the result of this thread is we are having some consens on some specfications and people can learn more about the inner workings of TMS computers, it is totally worth it. And with FPGA as hardware option there are no big expenses I see coming. First step would be having some specs, that can be picked up by anyone interested. I am not so keen about extra features but rather getting a clean design where we no longer have waitstates or unnecessary compromises. A computer where one can switch between original TI gaming speed and maximum speed like intended with the 99/8 and 99/5. A computer where one can load the system like a 99/4A, or use the whole 64K RAM for his own program. We have two successors that got produced and some which were prototyped. They all have one thing in common. They are no longer produced/available. Basically if there is one to be produced, which features should it have. Instead of big new features on hardware side I rather feel like on the software side we will have new ways of doing things. Using the internet to search and load software/data into the memory and stuff like this. If we would have a 16 bit PEB connection it would be a solid basis for every new hardware project.

I am curious to discuss possibilities, theoretical and practical, about what could be changed/improved while staying with the 99/4A mainboard. And second what are the possibilities of a new Tms based Computers. We have seen the efforts that went into 99/8 and 99/2, the 99/4B, the 99/5, the 990 mini computers, the geneve, the 9995 breadboard by Stuart, the SGCPU by Snug, the TMS99105 fpga based computer by Erik. I am wondering on what could be achieved, if we are free to redesign everything around the CPU family. As far as I read it, TI did decide for many compromises when designing the 99/4A. We only have an 8 bit bus to the PEB. Most memory and devices are connected via 8 bit. Many Cpu signals are not passed onto the I/O Bus, or the signal is inverted. Afaik all the Cpus have an address range limitation of 64KByte. There are memory mapping possibilities that could bring us 16 (like the 99/8) or 64 MByte (like planned on the geneve 2). What would the best TI computer have as specs and can we create it? This also goes a bit into the direction when does it stop feeling special to all of us, when does it stop feeling like a TI. So some questions I can think of to start: Which Cpu should we pick? Will it be Fpga based to be able to overcome limitations that even the best Cpus have? Can we do a full 16 bit data bus and design a PEB using that or could we even use the existing PEB for a 16 bit data bus by switching to another interface card? How do we deal with the Grom approach used by most 99/4 software? We could only reuse the Grom0-2 chips from the 99/4A in higher numbers, but that would introduce dependencies to the grom system software part of the OS. Would the F18A be the video chip we want? Afaik the only limitation in comparison to the 9938 and 9958 is the video ram size. What would be the advantages/disadvantages or the VDP to be using Cpu Ram (like the 99/2). How would the memory map look like? I always feel a bit disappointed seeing on the 99/4A so much memory space is permanently assigned to Cartridge space, Console Rom, DSR Rom and the user (or an user program) can not use all 64k memory for a certain program. Can we copy the system rom from an Eprom chip into the RAM when the computer is turned on? Or is there a nicer approach? Are CRU based DSR the thing to go for? Or is there something smarter already? To also discuss the 99/4A topic: I am thinking on things like replacing the System ROM by fixed versions. Providing some Grom 0-2 replacement pluggable circuit. I was amazed by Matthew on his F18A. He stayed compatible to the mainboard while suddenly providing the 16K of Video Ram from his FPGA board, providing additional 2K of ram and providing direct access to the registers and video ram for the virtual Co Processor, a Tms9900. Or think of the solution that Erik Piehls showed where we attached his device to the I/O port and simulating a 640KByte cartridge (i think it was the XB2.7 suite) with having zero at the cartridge port and with having zero mods done to the mainboard. This intro might sound a bit fuzzy but so seems to by my knowledge on this hardware-dominated topic.

Hi, this is Klaus. We managed to dump the 99/2 on the last weekend. So now it is time to complete the picture by also getting the other machines into the next preservation stage. We will try to dump the system roms of the never released/produced CC-40+, Compact Computer+. Steve Eggers is having one prototype unit and according to acadiel also ksarul is one prototype owner. The basic steps will be started off like acadiel managed to do all his dumps on the CC-40 unit.

is there an estimate when TIPI is available again to be bought?

website got fixed.

yes, when i discovered it on friday, the provider had reported having many issues. now those seem resolved. so either they screwed up or it is really unrelated. will check

U2, U3, U12 naming is coming from my PCB. U2 is stacked as stated in my post. i only took the Tech pdf page 1 to map 0, 2, 4, 4B to those locations.

Circuit Board is labeled with 1055197-1 Eproms are stored on the sockets labeled U2 2x TMS 2564JL-45 MEP8327 (0000, 4000B) U3 1x TMS 2564JL-45 MEP8327 (4000) U12 1x TMS 2564JL-45 MEP8327 (2000) assignment according to page 1 of the TI992_Tech_Diagrams.pdf

Here is the last Eprom, that was missing til now: romB-4000-5fff.bin dump-succeeder.bas 1 GOTO 100 10 CALL POKE(-7936,2,12,224,0,29,0,2,0) 20 CALL POKE(-7928,94,0,2,1,225,128,2,2) 30 CALL POKE(-7920,2,0,204,112,6,66,22,253,30,0,4,91) 40 CALL MCHL(-7936) 100 OPEN #1:"HEXBUS.20.B=9600.D=7.S=1.P=E",OUTPUT 110 FOR I=-7808 TO -7297 120 CALL PEEK(I,P) 130 H1=INT(P/16) 140 H2=P-H1*16 150 IF H1>9 THEN 180 160 H1$=CHR$(48+H1) 170 GOTO 190 180 H1$=CHR$(87+H1) 190 IF H2>9 THEN 220 200 H2$=CHR$(48+H2) 210 GOTO 230 220 H2$=CHR$(87+H2) 230 PRINT #1:H1$;H2$; 240 PRINT H1$;H2$; 250 NEXT I 260 CLOSE #1 Line 1 was commented out when I wanted to run the POKEs. Line 20 the first value after the address -7928 got increased by 2 to jump by 512 bytes. Each run transmitted 512 bytes over the Hex-Bus via the RS232 device. This was done 16 times to get 8192 bytes in total. Next step is verifying the ROM dump against the print out we have by making the binary match the formatting of the print out. This should reveal any diffs best. Many thanks to Mike Wright and M.Zapf!

the hidden bank is currently being dumped. the remaining ones can be found here http://atariage.com/forums/topic/258370-ti-992-general-system-rom-dump/?do=findComment&comment=3618660

Big Success!!! First 512 bytes seem to match the hidden rom bank of the ugly print out from the documents we have. I have recorded the moment in a video which will is currently uploaded to youtube.

and in Line 3 we have the first two written values as the repeater count, right? 0, 16 means repeating 0016 times, i am trying it now with 512, therefore 2, 0

WORKED!!!

thank you a lot. it seems we are almost there. the program returned to the title screen. however the ram shows the correct values of the hidden(!) bank at -7808 to -7792.

can you post how to change the program? I would be needing hours

again, bank #3. the non-hidden one. with 29,0 it crashed into an internal server error again.

it did run now. will peek into the area to see if it did what we want 1 CALL POKE(-7936,2,12,224,0,30,0,2,0) 2 CALL POKE(-7928,64,0,2,1,225,128,2,2) 3 CALL POKE(-7920,0,16,204,112,6,66,22,253,4,91) 4 CALL MCHL(-7936) 5 PRINT "DONE"

crashed with 29,0 in line 1. will try 30,0 in line 1 now. please stay available.

Yes, this is matching the first 32 hexadecimal values of the dump of bank 3. so the switching was not working, the copying DID work! 00 00 06 A0 26 58 06 A0 26 2A C8 02 EA 62 04 E0

so all that is not working yet is the bank switching, or?

this worked. i got a PRINT statement executed that followed those two lines.

yes, will do that Michael. However I peeked now in the expected area where we wrote the assembler code. That was still intact. And I peeked the 16 values from -7808 to -7791. It seems writing was done, it is matching the bank #3, however the non hidden one. 0,0,6,160,38,88,6,160,38,42,200,2,234,98,4,224,242,29

1 CALL POKE(-7936, 2, 12, 224, 0, 29, 1, 2, 0) 2 CALL POKE(-7928, 64, 0, 2, 1, 225, 128, 2, 2) 3 CALL POKE(-7920, 0, 16, 204, 112, 6, 66, 22, 253, 4, 91) 4 CALL MCHL(-7936) 5 PRINT "DONE" Is this correct? It did crash. EDIT: edited to change the buffer to >E180 Now it did RUN but there was it was not performing line 5, the PRINT command. Could it be that the assembly code exits wrong so there is no nice return to the basic prg?

okay. i will try to relocate it now and check the results EDIT: poking all wanted values to E100 (-7936) was successful. Now I will try to run MCHL in addition. And if that works as well I will try to add my dump program.