mizapf

Well, except for the AMIGO mapper chip we know in detail what is happening on the board. And for that one we know the external behavior and the equations. So it could certainly be reverse engineered; in fact, in a virtual sense it is what I do in MESS. The only issue today is that you do not get GROMs anymore, so you'll have to build a hardware emulation of GROMs.

Is something useful in this file, possibly? I have not studied it yet, being quite long. ftp://ftp.whtech.com/hexbus_cc40_ti74/cc40%20ti74%20hexbus.txt

Follow the link that Lucien posted above. It explains what you can do. Essentially, using the arrow keys (or short ESDX), you move all tiles to one direction (as if you tilted the board). When two tiles with equal value touch each other, both are united to a "sum tile". Try to push that value up to 2048.

Here's the RPK for MESS users. Rename ".zip" to ".rpk" (the forum server does not like rpk files). 2048.zip

OK, I'll keep a copy of your dumps. Next thing important for an emulation are schematics; if we don't have that, some architectural overview would be required at least.

As I said above (#7), the reported address is wrong. The problem actually occurs on the 1304 address (HANDSHAKEOUT/IN). If you set the 1302 address, this is the one that Diagnostics also found as good (but falsely calls it 1301). When you write to 1300 you turn on the DSR. When you read that value you will always get 0 (according to Thierry's description). The same is true for 1301, since the CRU address space only knows even addresses (means, 1300=1301). Actually, if you connect pins 1 and 10 of the PIO, the test should succeed. If everything is OK.

ROFL ... not again ... :-) If I ever were to design a forum software I'd make it use a increasingly stronger yellow background with coffee cup marks and dog-ears for postings older than six months. For people like me who just can't read the date before writing. As for the format: Sorry for me being alerted, I just read "deprecated", and I understand this as "don't use, it won't be supported any longer, usage may become illegal". I think it does make sense to agree on a standard format, and TIFILES is a good way to exchange files between our emulators and also with the real machines. I just wanted to say that here's someone who makes use of the file name in the format.

Well now, here's my solution (couldn't resist): #!/bin/bash test -f out.hex && rm out.hex IFS=$'\n' for line in `cat $1` do IFS=',' read -a v <<< "$line" printf "%02x " ${v[1]} >> out.hex done xxd -p -r out.hex > out.bin I guess you do not really need the offset. From n things you consider feasible in bash, there are at least n+1.

If there has not been a regression in the meantime, Tomy Tutor/Pyuuta was fixed by me some time ago. The problem was that the decrementer in the 9995 was not correctly implemented by me, and the Geneve did not make use of it, so I did not notice. This was one of those harder problems - trying to get a machine running for which you have absolutely no information. The fix should be included since release 0.151.

Ah, OK , I do have them already. What the documents do not fully reveal is how exactly the "burst transfer" from SRAM to the map register looks like. I guess that writing to the transfer register launches some counter inside the AMIGO which counts up the addresses on each clock pulse while HOLDing the CPU on the other side. The visible functionality seems to be clear to me. I'll check the docs once more, maybe there's some information that I did not make use of.

You can use the xxd command. First you must create a text file consisting of the hex values, then pass it though xxd. Example: Suppose you have a text file input.hex containing "ff ff 83 7c" as ascii text; then xxd -p -r input.hex > output.bin If you have decimal values and need the hex values you can use the printf command to create them. #!/bin/bash VALUE="200" printf "%2x" $VALUE > input.hex From here on, happy shell programming. :-)

I think I do not yet have the PAL equations of AMIGO - could you send me a copy? Some time ago Ciro and I did some timing measurements. I wanted to find out what actually happens when maps are changed. This indeed takes considerable time because the AMIGO performs a DMA access while HOLDing the CPU.

?? Including the file name in the TIFILES format is a very reasonable feature of this format, nothing to consider deprecated, sorry to contradict. Me, I'd really like to keep that name in the format. I do not want to be forced to use the TI file system name in my exported TI files (which I consider TIFILES to be); we obviously have some different requirements here. TIImageTool will always include the TI file name into the TIFILES file and if it fails to find one, suggest the PC file system name as a fallback. That is, I would appreciate if we keep that file name feature in TIFILES, but you are of course free to ignore it. Just please don't declare it illegal, or we'll get two incompatible TIFILES formats, which would be a (lowercase) mess.

I was just wondering whether Stuart actually implemented a full TCP/IP stack, but as I saw a lot of the heavy lifting is done by the Lantronix device. Some of you might remember that I once kicked off a project to implement TCP/IP on the Geneve (around 1996), but I stopped shortly after enabling my Geneve to answer ping requests from my PC. If you want to get a full Internet connection from the TI/Geneve using a simple modem or a direct serial cable connection (and not the tunneling technique of the Lantronix) you have to implement PPP, IP, and TCP, for DNS access also UDP, and maybe you can get along without ICMP, but in the end, the HTML rendering is the least concern of all.

Oh, my good old speech board ... LOL. Some points: 1. No, I don't build those boards anymore. Look at the date: 1995. Don't even remember how I did it. :-) 2. What I remember is that during that time I learnt how to program GALs in my university courses. So this was kind of a practical application. 3. As I noticed (much later) it is not fully complete: I forgot to check AMA/AMB/AMC which makes my Geneve produce some burping sound now and then. 4. Apart from that it has some ugly error on it. IIRC I mixed up the pins of the regulators. 5. This is actually a self-edged board; I think I needed some attempts to get it properly aligned. BUT one good point: I designed the board with Eagle. I noticed that there are some people who know Eagle, so if I can find the file it can probably still be read and improved. And maybe there's the GAL programming somewhere. I'll have a look.

Really? I think I never used the Extended Basic Ref card, but my E/A card did suffer a bit over time. As you see, typically stained, bent, a bit torn ... let alone my markings inside ...

To be honest, I only have those three as real packages; I don't remember how I got the other ones. I played the Zork games with the standard 40-column interpreter, but later I used the 80-column interpreter on the Geneve (written for the V9938) which was pretty much fun.

Like those?

Infocom titles like Zork 1-3, Planetfall, Stationfall, Deadline, Hitchhiker's Guide, Hollywood Hijinx, Infidel, Leather Goddesses, Lurking Horror, all of which I have on my Geneve hard disk?

Ah, I see. OK, thanks; then it indeed makes sense to mask the GRMRDY by the GSEL, as it is done in the console. One minor detail, as far as I understood the TMS 9900 operation; hopefully correct, I implemented it this way in MESS :-) : Each read access by the TMS9900 is at least two cycles long. First cycle: Set the address bus. The addressed device may now set the data bus, maybe shortly after, but slow devices take more time. Also, the device can decide to lower the READY line. Second cycle: Probe the READY line. When it is H, sample the data bus, and take the value as the actual value from the device. Then release the address bus. Read operation has completed. When the READY line is L, keep the address set on the bus and wait for the next cycle. Each write access by the TMS9900 is at least two cycles long. First cycle: Set the address bus. Shortly after (when the address lines are assumed to have settled), set the data bus. Second cycle: Probe the READY line. If it is high, release address bus and data bus; write operation has completed. If the READY line is L, keep the buses set to their values, and wait for the next cycle. Accordingly, the description from above should be slightly adapted like this (but essentially telling the same): - MDIR, MODE, and GSEL are asserted according to the address put on the address bus - The READY line is pulled down immediately due to GRMRDY being switched through. This does not bother the CPU before it enters its cycle 2. - If the operation is a read operation, the CPU goes into cycle 2 and will continue to wait until the READY line goes up again. Shortly before, the GROM must have asserted the data bus, and the CPU picks up the values and completes the cycle. - If the operation is a write operation, while READY is already low, the CPU will put the value on the data bus in cycle 1. In cycle 2, it detects a READY=L and goes into wait state until the GROM raises READY. - This will make the CPU release the data bus and address bus, thus resets the GSEL and so disconnects the GRMRDY. As you said, in that moment, the GRMRDY will fall back to L, but the CPU will not notice, since its current memory access is completed.

Keep in mind that there are different kinds of memory. The memory modules that we can buy for little money is all DRAM, that is, they need a memory controller. This leads to a more complicated design than just soldering some SRAMs on the buses.

I had a look at Michael Bunyard's documents. He says The GRAPHICS READ ONLY MEMORY (GROM) chip is in essence a ROM chip with an internal address register. Additional logic is also included to allow the paralleling of up to 8 GROM chips (there are three Console GROM chips, and they are connected in parallel). From the user's point of view, the ROM array is organized 6K x 8, and based at zero in an 8K byte space. The GROM chip is a synchronous chip that is clocked by a square wave 447.443 kHz clock obtained from the TMS 9918 VDP chip. The GROM chip runs partially closed loop with respect to the TMS 9900 driving it in the sense that the "READY" input to the TMS 9900 is controlled by the GROM chip "READY" output during GROM accesses. GROM READY simply indicates, when it is at HIGH level, that the CPU-dependent portion of the GROM cycle has been completed. It does NOT MEAN that the FULL GROM cycle has been completed. GROM CHIP SELECT MUST REMAIN INACTIVE (at a HIGH level) FOR AT LEAST 2.5 GROM CLOCK PERIODS BETWEEN SUCCESSIVE ACCESSES. This translates to 5.6 µs for a 447.443 kHz GROM clock. The GROM chips for the P-CODE in the Peripheral Expansion Box are clocked with 375 kHz square wave clock; therefore, 6.67 µs must be allowed from the end of one access to the beginning of the next. THIS IS A SOFTWARE RESPONSIBILITY. There is no hardware check. I remember I once read these lines. This description seems pretty detailed, but it would have been better if we had a timing diagram for the GROM. From the description I assume the following: When reading the GROM, we get the byte from the internal buffer. During the time of moving that value to the output buffer for the data bus, the READY line is pulled down. After one GROM clock cycle, the READY line is put high again. (This is not clear from the above text.) The CPU thus concludes the current read access. In the following 2.5 GROM clock cycles, the address counter is increased, and the next value is fetched and put into the internal buffer. This means that if we attempt to read earlier, we will have either an undefined or an old value. Of course, it is a bit of a challenge on the TI to execute a second read operation that soon. An operation like MOVB needs at least 14 cycles (=4.6 µs), so if we use two MOVB @>9800,R0 directly one after another in scratch pad RAM, maybe this could have an effect. The Geneve would be clearly able to achieve that, but it has no GROMs. What I still wonder is: Do these timings also apply to address counter readout / setting?

Just did some quick browsing through the PGRAM+ manual - as it seems, it mainly describes its own functionality but not the internals of real GROMs. But maybe I need to have a deeper look inside. I'd be rather interested in things like timings and internal architecture of a GROM. All that we have right now may be derived from the external behavior only, e.g. our theories about the behavior in the upper 2K, address counter, and data prefetch. Is there possibly a patent text concerning GROMs?

Some of the words are still inherited from the previous maintainer, as I noticed (I just copy-pasted them). The bank is named "ID" in the text (lines 70++). I'd suggest not to call it "bank", since we use that term to call a set of 8 GROMs with the same access ports as one bank (at least I do). So one complete set of GROMs consists of 8 GROMs, one for each ID, and thus for each memory region. (I think the GROMs are even hardcoded for that ID, since they have different circuit names. Reading it again, I seem to implicitly assume that the reader knows about the three GROMs in the console, so I agree that I should add some more words. It is correct that devices like the GRAMKracker override the internal GROMs, sitting on the same IDs (0,1,2). I wonder, however, how they can override both 0 and 1 bits. If they are kind of open collector outputs, only one level can be overridden. Or they have some output resistors which makes it generally lose against a more powerful driver on the bus. I do not know of any technical documentation from TI concerning the GROMs. Would be pretty interesting, though. The HSGPL expansion card also provides new GROMs at that locations, but it is also recommended to remove the console GROMs when using the HSGPL. (N.B. that the only "real" GROMs are from Texas Instruments, and in all other occasions we have GROM emulations by using ROM chips with a circuit for latching the address). The concept with the GROM banks with ports on different memory addresses is not directly related to GROMs as such. In fact, there could be 256 banks with 8 GROMs each because the first base address is 0x9800 and we have free addresses until 0x9C00 (which is the write port for 9800), so that yields 256 addresses in 4-byte steps. However, there are no precautions in the console to make use of that concept - except for the routine in the operating system (which searches for 16 banks) and for the Graphics Programming Language (GPL) which is used for programs that are stored in the GROMs. But there are no specific circuits to support it. One additional variant can be found on the P-Code card. It has its own GROMs and puts the ports on addresses 5BFC, 5BFE, 5FFC, and 5FFE, but only when the card is selected. When unselected, the GROMs on the card do not react.

Maybe this is helpful for a C implementation: Have a look at the GROM emulation that I use in MESS. http://mamedev.org/source/src/mess/machine/ti99/grom.c.html Much of the information provided by tursi and from Thierry and other sources can be found in that source code. Maybe also some assumptions. :-)