mizapf

I found the $REPEAT ... $UNTIL structures quite interesting. Also, they seem to have an issue with special XML instructions (XML2); they used a DATA line to force the GPL assembler to produce the intended object code.

BTW, as I said, the "official" GPL sources look a bit different to the source code in TI Intern or other GPL listings. Take this as an example of how TI engineers wrote GPL programs (taken from the 99/8 sources, power-up routine): PWRUP$ DCLR @>CE CLEAR SOUND LIST INDICATOR * RESET SPEECH 9 TIMES, IN CASE IN SPEAK EXTERNAL ATA ST 9,@FAC ATA SPRSET ATA ST >70,@>1100 TURN OFF SPEECH DEC @FAC ATA BR SPRSET ATA ST >9F,@>100 TURN OFF SOUND ATA ST >BF,@>100 ATA ST >DF,@>100 ATA ST >FF,@>100 ATA DST >FF7E,@STACK INITIALIZE THE SUBROUTINE STACK ATA CLR @GMODE ATA CALL MODE$$ ATA * DST >021C,@SCLEFT USE 28 COLUMNS GFH 8/08 MOVE 7 FROM ROM(#VDPRG$+1) TO VDP(0) but now move sgt,pct ATA MOVE 7 FROM ROM(#VDPRG$+1) TO @SHAD0 ATA * * LAST POWER UP ROUTINE DOES SCREENS AND MENUS * * *** THIS INITIALIZATION IS FOR THE ARMADILLO BREADBOARD #2 ONLY ATA * CLR @0 CLEAR CPU RAM MOVE >71 FROM @0 TO @1 MOVE >3E FROM @>00 TO @>82 MOVE >B FROM @>00 TO @>74 MOVE 22 FROM @0 TO @>C2 ATA DST >0605,@CRLIST+1 DISABLE KBD INTERRUPTS ATA I/O @CRLIST,3 DST >1801,@CRLIST+1 TURN ON AUDIO GATE ATA I/O @CRLIST,3 INV @CLEARU WRITE A ONE TO CRU DST >0102,@CRLIST+1 ENABLE VDP AND EXTERNAL INTERRUPTS I/O @CRLIST,3 DST >1601,@CRLIST+1 TURN ON CASSETTE MOTOR ATA I/O @CRLIST,3 CALL TON1$$ BEEP AT PERSON ST 8,@>FD INDICATE 16K RAM ATA DST #>3FFF,@MEMTOP WE ALWAYS HAVE 16K OF RAM ATA MOVE 1 FROM ROM(#H20) TO VDP(1) DATA XML2,FILLV,#>300,#>D00,0 CLEAR 4K OF VIDEO RAM ATA * (LESS SCREEN) ATA DATA XML2,TIMVDP Determine Euro/USA model GFH CALL INITC1 CLEAR SCREEN AND LOAD LARGE CHARS ATA MOVE 32 FROM ROM(#TABLE$) TO TABLE(0) **** MOVE 512 FROM ROM(#CHAR1$) TO CHAR(>20) ATA MOVE 80 FROM ROM(#TIBUG$) TO CHAR(1) **** ALL : : ATA ST 5,YPT RSCAN ST YPT,@KEYBD RESET ALL KEYBOARDS FOR SCAN ATA SCAN DEC YPT BR RSCAN DCLR YPT $REPEAT ST >60,@RKEY ATA $REPEAT FMT 2('@RKEY'),>11^,30<,2('@RKEY') ATA SUB >12,YPT ADD >8,@RKEY ATA $UNTIL @RKEY .EQ. >E0 ATA $UNTIL YPT .EQ. 3 HOME UNLM ATA FMT 5^,15<,'1,2,3',29<,'4,5,6',29<,'7,8,9'; 8^,16<,':READY-PRESS ANY KEY TO BEGIN:' LISTM ATA MOVE 17 FROM ROM(#TI) TO RAM(296) MOVE 29 FROM ROM(#TI1979) TO RAM(706) ATA MOVE 8 FROM ROM(#HC) TO RAM(364) ATA 8/12

The authors of the tms5220 emulation in MAME discovered that the description in the patent is incorrect in some places. This was found by "decapping", meaning that the chip was opened, photographed, and then the logic arrays and mask ROMs were "read" from the photograph. No, really.

OCR? Not really. This is what I get from GROM0. As I said, it is just a matter of creating a syntax that is understood by the GPL assembler Rich is going to use. gpl0.txt.zip

What is the "next" GROM address 0x2000? I did not switch the GROM base. Or do you think of the next GROM, i.e. the counter is 0x4000? Then why does it return 0x2000? Without having exact details on the GROM internals, it seems to me that the address counter in the GROM holds all 16 bits, and the respective GROM only responds on the bus when its ID matches the first three bits of the address.

I just had Ciro run a test on his TI-99/8, and I suppose it is using "real" GROMs. My test program set the GROM counter to 37FF. After a read, the next address is 3800 (read from the address counter). Also, the next address after 3FFF is 2000, as the address counter shows. If you are interested and if you can transfer a D/F 80 file to a real TI, I can upload that tool here.

My TIImageTool has a GPL disassembler. You could use a GROM dump and create the source code from it. However, I had the problem that there was no standard for GPL syntax. My diassembler, for example, uses a different argument order than shown in TI Intern listings. In fact, the official GPL source files (which I have for the TI-99/8) also adhere to the version I implemented. Moreover, the official GPL sources contain constructs that disappear in the object code (like loops). So it depends on which GPL assembler you plan to use whether the output of TIImageTool is useful or not.

If you are interested and feel adventurous enough, have a look at the TMS5220 implementation in MAME (http://git.redump.net/mame/tree/src/emu/sound/tms5220.c). This is a precise implementation according to the specs and patents, and in my ears virtually equivalent to the real chip.

Even better, just think about the skiing restaurants in the Alps. Ever tried to climb down the stairs with hard ski boots?

With static screens, this should have been feasible for our TI (with a much better speech synthesis!). If anyone feels like creating such a game, I'd like to get a version for standard 9918 (or 9938 <grin>). And the number 42 with rice instead of noodles.

I already thought you talked about "Impossible Mission" from the C64 - a game whose TI port I'm still waiting for ... "Another visitor. Stay awhile. Stay forever ..."

Looks good enough, Robert. One last thing, could you please give me the dimensions of the box (width/length/height)?

What is the issue with hyperspin? I just heard about them with this request.

I got a request from someone from the HyperSpin project who wants to create an isometric view of a TI cartridge box. Unfortunately, I do not have any boxes left; long ago, I put all cartridges and manuals in a single cardboard box. Is someone here who still has such a white Command Module box in good shape and could put it on a flatbed scanner and scan all six faces (front, back, left, right, upper, lower) at 300 dpi in color? This would also be useful for us, in terms of conservation.

Don't mention the war!

Sounds to me as if the web server / CMS delivers the wrong MIME type. Curiously, I tried Wireshark and saw that there is a HTTP response as application/octet-stream, not image/* (which would cause the browser to open a dialog window as reported). Unfortunately, the transfer is gzipped, so I could not look deeper inside.

Hmmm ... the log tells me that there are actually lots of accesses to the emulated SAMS card, but I neither see any confirmation on the TurboForth screen. Mark Wills should be able to say how exactly TF determines whether SAMS is present.

What should it do? If the SAMS memory card has no ROM, you won't see any difference until you make use of it. At least it provides the 32K memory expected by Editor/Assembler. If the real console shows a visible reaction with the SAMS card, it obviously has a ROM and we need a dump from it.

@OX.: There is no SAMS ROM in MESS. If there is a real ROM, I have not hooked it into the implementation. If the SAMS card indeed has a ROM I would certainly be happy to get a copy and to include it in MESS! @RasmusM: I do not know whether the MAME core supports the HFE format. If it does I'd still have to enable that format in my parts because at this time I'm only checking for sector dumps and track dumps.

The CPU bus is 16 bit. There is a 16/8 multiplexer in the console, going out to the I/O connector and the cartridge port. The task of the multiplexer is to split the 16 bit word by first latching the upper byte, passing the lower byte on the external bus with the least significant address bit set to 1, then routing the upper byte to the external bus with the LSB of the address set to 0. During the whole process, the multiplexer puts the CPU on wait state. There are two components in the console which were located before the multiplexer: the 8 KiB "Monitor" ROM and 256 byte RAM. Those were not affected by the slowdown. One way to make the console significantly faster was to connect additional RAM circuits directly in the console before the multiplexer, and to disable the wait state creation when the access hits the area of the RAM (2000-3FFF, A000-FFFF). The Speech Synthesizer and all external devices connect to the I/O port, so they are behind the multiplexer.

Yes, but although this has often been cited as a point for 8-bit-ness, it is not really justified. The TI-99/4A has always been a full 16-bit platform, albeit with a time-multiplexed 8-bit external bus. The processor architecture is 16 bit, which is significant for the width. Every memory access in the TI console comprises 16 bits. I think this was mainly due to the envy of those other home computer platform users who had to get along with 8 bit, telling us that ours were an 8 bit as well. No way. :-)

If we were to implement a F18A in MESS, we would need a precise documentation of its (visible) operation. If we also want to do it cycle-precisely, we need to know the micro program commands that are executed on each cycle, similar to the description of the TMS9900. See 9900-FamilySystemsDesign-04-Hardware Design.pdf on WHTech, pages 4-89 ff. It is not important to know how exactly the microoperation is done, only what is the result after the cycle. In that sense this is already an interpretation of the real machine operations and not a 100% mapping into software. The only thing (apart from the fact that I cannot afford the time right now, as I said) that concerns me is that I heard the internal cycle rate is 100 MHz. This is 25 times faster than the CPU emulations I have been involved in, so I cannot tell whether if in the end we would end up with a simpler emulation.

I just got this link from Berry: http://www.youtube.com/watch?v=CpS6YbQG03 documenting our TI-Treffen in Eindhoven.

Matthew said he could imagine to write a reference implementation, but this does not mean it will be included as-is into the MAME/MESS source code. It will, of course, eventually need to be rewritten in C++.

And I was just reacting to Rich's rant on command line usage.