jens-eike

That is normal, if it is NTSC - ringing of the video signal at sharp edges (contrasts) gives all kinds of colorful effects :-(

Remove the small sticker from the write protect notch Seriuosly, check your firmware - old versions were read only for TI formats... http://hxc2001.com/download/floppy_drive_emulator/index.html According to http://hxc2001.com/download/floppy_drive_emulator/sd_hxc_floppy_emulator_firmware_release_notes.txt firmwares above 1.8.2.24 have fewer problems with floppy writes.

There is some info on Tomy Tutor (Pyuuta) hardware here: http://www.floodgap.com/retrobits/tomy/hardware.html More detailed schematics: http://www43.tok2.com/home/cmpslv/Pyuuta/EnrPt.htm (Japanese text)

The Test program logic in the original post may have a flaw(?). When testing VDP-RAM and not taking into account the auto-incrementing of VDP addresses, that could give the above pattern. But then, it should give the same error on all locations...

Look at Stuart's site: http://www.avjd51.dsl.pipex.com/tms99110_breadboard/tms99110_breadboard.htm

The TMS991xx can add wait states to any operation (memory, internal, cru), so it should be possible to use the 9902. The 9901 can be replaced by '251 (input), '259 (output) and '348 (interrupt priority) TTL chips without speed penalty. Bonus: the TMS991xx can do parallel I/O for CRU addresses above >8000

Another note: check your timing requirements. 100ns RAM could be too slow for worst-case operation. Consult the data book, from address stable to data in is much shorter than 330ns! According to my TMS9995 Data Manual (December 1984), page 56, the access time is 3/4*tc2-135 (3/4*333-135=114ns with a 12MHz clock, at 16MHz: 3/4*250-135=52ns). Subtract any delay from TTL buffers or decoders like 74LS244 (30ns) or 74LS138 (39ns) and a '245 (40ns) buffering the data bus (maximum values from The TTL Data Book 1987). As you can see, LS-TTL logic is not going to make it, that's why TI invented the automatic first wait-state. Using faster logic (ALS/F/ACT...) and really fast RAM (628512 is available in 55ns) can do the trick.

That is just what the Cortex does: copying the content from the EPROMs to RAM, then running the OS from RAM. Great idea, you can modify any BASIC command :-) What is wrong with ROM, if you don't have to worry about slow access speed...

Actually, both CPUs run on 12MHz. The 9995 has an internal clock generator deriving it's microcycles from the crystal, externally, all we see is the memory cycle and the -phi clock output. The 9900 gets four clock phases from it's TIM9904(A), derived from a 12MHz crystal (older TIM9904 use a 48MHz crystal, most 99/4 have these). Peripheral chips like the TMS9902 use only one phase of the clock signal, so a 3MHz signal -phi3 controls most of the timing. Note: -phi3 is one fourth of the clock signals, so it's duty cycle is about 80ns active (low) and ~250ns inactive (high) (+/- rise and fall times). Early 9901s had a problem with the 50% duty cycle of the 9995, so TI produced chips marked TMS9901-95 and TMS9902-95 for compatibility with the 9995.

Before getting into trouble changing to a PC power supply and modifying all your cards (and remembering the mod everytime you test another card/your cards in another box), you should test the rectifier diodes on the PEB power board. When I got my first HDD, I upgraded the regulators to 2A types, but the diodes weren't up to the load. It took me 5 fuses to diagnose the problem. Now the box is working without problems since 1988.

Thanks for posting the new files - here is my test in clear ("natural") PLA on a Velleman K8200 (3Drag) printer using RepetierHost 1.0.6 and the Cura slicer:

Now we really need Thierry's site... The problem I could imagine is the console interrupt routine. When the 9901 timer issues an interrupt, the console checks for VDP and cassette interrupt, then DSR interrupts (where an error in the RS232 card prevents further service), and when nothing is found, your interrupt routine gets it's turn. This way, you will lose a lot of time...

Above was a "Princess and Frog" cartridge for $500 - THAT WAS A BARGAIN!!! It gets worse: the Infocom adventure "Leather Goddesses of Phobos" no cartridge, just a disk with manuals at EUR 480 (approx. $600)! Anybody crazy enough to buy this???? http://www.ebay.de/itm/LEATHER-GODDESSES-OF-PHOBOS-Infocom-TI-994A-9640-DISK-OVPBAGGIE-english-/261680015506

After the world ends, tell it to the other people at Milliways: http://www.youtube.com/watch?v=ucNYLsjKaTQ

50464 are 64k*4bit. Two of them are 64kByte, so your card is 512k with 16 chips.

Some good reading about Karl Guttag's work with the TMS99xx family: http://spatula-city.org/~im14u2c/vdp-99xx/ About the 8/16-bit bottleneck: In his notes, he mentions the 9985 originally planned as CPU for the 99/4. The 9985 was derived from the (flawed) 9940, it was an 8-bit CPU made to work on the 16-bit instruction set....: Quote: "The 99/4 was originally slated to use the 9985 CPU and not need the 9901 at all. The 9985 CPU was going to be a variation of the 9940 “microcomputer” with embedded EEPROM. The 9985 replaced the EEPROM with 256 Bytes of on-chip RAM. The 256 bytes of on-chip RAM was for the GPL and Basic interpretation, and had to be shared between instructions and data. The 9940 was a terrible design, it was big, slow and had a huge number of design bugs and to top it all off, there was huge pressure from management. So the 9985 was waiting behind getting the 9940 debugged and the 9940 was very hard to debug the way they designed it. [...] Now the 9900 had a 16-bit CPU with a 16-bit ALU and a 16-bit external interface but it was pretty inefficient and took 14 clock cycles to do a register to register add. The 9985 had only an 8-bit ALU and 8-bit I/O and took about 10 cycles to do a register to register add. Inside the 9985 the interface to the 256 bytes of RAM was also only 8-bits wide. To emulate the 9985, the 99/4 had to add hardware to covert the 16-bit bus coming out of the 9900 to act like the 8-bit bus of the 9900." source: http://spatula-city.org/~im14u2c/vdp-99xx/e1/99-4_History_By_KG_in_answers_to_Matthews_Questions.doc

A "normal" TI DSDD disk (40 tracks) has 1440 sectors (=360k), so your example is missing half it's capacity. Try 18 sectors/track and your 80-track disk gets up to 2880 sectors.

You really don't want to play games with original TI joysticks, they are not famous for responsiveness. Better put them in your collection (if you get a pair) and use an adapter to play with your favourite Atari-style joysticks. To build your own adapter: http://mainbyte.com/ti99/hardware/cables/joystick.html

That is it! I found my disk, and in the source code it says "The Bill Gronos Sound Show"

I remember a very simple light show program, displaying different colors for the frequencies detected at the cassette input. But I have no clue to the name or on which disk I have it.....

Must be the 9902 based nanoPEB. from Stuart's source code: *Set port 1 to 1200 Baud, 7 data bits, no parity, 1 stop bit. LI R12,BA9902 CRU base address of 9902 in NanoPEB. SBO 31 Reset 9902. This sets /RTS inactive high, so the * RTS output line to -ve voltage.

Or, simply build your own: http://acg-bonn.dyndns.org/acg/download/tiif.zip schematics and updated program included.

or, you could glue a (thin) strip of plastic to the bar, before making the mold.

You guessed right: count me in!

Some RTC/SRAM chips access the clock registers at their highest bytes. Interesting effects can be expected, when the LOAD interupt vector changes due to advancing counters... A clock/SRAM would make sense as a CRU activated device, the SRAM could hold the DSR for clock access. Lower RAM addresses should be write protected to protect the DSR (accessible only for DSR updates).