FarmerPotato

I'm looking for a supply of V9990 to use with the TI-99/4A (we had V9938/V9958 add-ons already.) I was able to get one quote for MOQ 50 pcs @ $24 each. Realistically, I only need 1-10 pcs for development. The necessary dual-port VRAM is about $5 for a set. Are there any folks interested in buying V9990 parts out of a lot of 50 (or more?) Related Threads

Supersketch The ADC and connector are the ringers.

I keep one of the original TI shipping cartons, from back when mdude was selling new stock. It has blown-in foam around plastic wrap, to create a custom cavity around the PBox. My other way of shipping a PBox has been to use a much larger hard-shell tote, at least 2 inches of foam around all sides of the PBox, and locking handles. My Pbox (for shows) has survived a plane trip and 5 moving trucks this way. The tote has gotten a lot of dings over the years, but the PBox (and two floppy drives) is still show-quality.

I second arcadeshopper's Hakko. In the past I have bought a FR-300 for myself and others. The current model is FR-301. You can get a deal here: https://www.tequipment.net/search/?F_Keyword=hakko fr-301 The extra nozzles are nice, but you can get working with the basic kit. You'll need to buy some more consumables though. I got a deal they used to have on an FR-300 desoldering + FX-888 soldering. There are usually deals for 11% off list price of Hakko stuff. Fry's used to have them on the shelf. There are more sophisticated ones out there, but the Hakko is the most affordable and a breeze to work with. Oh yeah, don't bother with the cheap knockoffs. The Hakko will last a long time if you take care to clean it.

Yeah, you're right that the schematic says ROM* is driven from the Y2* output, which is low when B is low. This is certainly an error in the schematic. Note that the author is not sure about where ROM* connects to the 139. They got Y2* and Y3* wrong. In order for the device to function at all, ROM* must absolutely be mapped in the address space starting at >4000. B = NAND(A3..A10) . 1Y3* = !B + G*. So 1Y3 must be ROM* for the ROM to be mapped at >4000 - >5FDF. 1Y2* = B + G*. So 1Y2* must be FDC* for the WD1771 to be mapped at >5FE0 - >5FFF. Anyway, the important thing is that S1*, S2*, and PGM* were not independent. So the adaptor is actually easier.

The 2764 needs PGM* high to read, I was referring to the adaptor that should tie the 2764 PGM* to VCC.

If S1*,S2*,PGM* are tied together, then the PGM* pin will have the wrong polarity. It must be high on the 2764, low on the 2564. If it is simply tied to VCC on the adaptor, that should fix it. This is a normal setup for a PBOX card. CRU Bit 0 is always DSR ROM enable. Only one card can have CRU bit 0 set at a time. This maps its ROM into address space >4000 - >5FFF. One minor thing you got backwards. ROM* and FDC*. The ROM* maps addresses >4000 - >5FDF while the FDC* maps addresses 5FE0-5FFF for the WD1771 registers.

Yeah!

I went over all the pins again and realized that PGM* is not the same (aside from being on a different pin). On the 2564, PGM* is LOW to read data, on the 2764 PGM* is HIGH to read data. You shouldn't try to program using the stackup; even if it works, it won't verify. You should just program it the way it wants to be, as a 2764, no stackup. So if you built my pinout, I didn't get PGM* right, so that might be your issue. Ksarul's adaptor just wires the 2764 PGM* to VCC, so it can work as a ROM, but you couldn't program through the stackup. I'm not sure what I'm seeing on Brain's schematic. The other Ksarul did is to short S1* and S2* leads into one G*.. Does that work? more about that later. On the 2564 2 S1* HIGH to disable outputs, LOW to enable 27 S2* ditto 22 PD/PGM* HIGH to power down, LOW to program or read 20 A11 23 A12 26 VCC On the 2764 22 G* HIGH to disable, LOW to enable outputs 20 E* HIGH to power down, LOW to enable chip 27 PGM* is HIGH to read, LOW to program. 23 A11 2 A12 26 NC, but should be shorted to 28 VCC like on Ksarul's. There is an expectation that the chip come out of power down mode (E* goes low) before outputs are enabled (G* goes low). But that doesn't matter here. So a better mapping for use as a replacement in a card might be 2564 | 2764 2 S1* | 22 G* 27 S2* | NC, or put 22 G* here but not in both 22 PD/PGM* | 20 E* 20 A11 | 23 A11 23 A12 | 2 A12 26 VCC | 26 NC, 27 PGM*, 28 VCC I see on Ksarul's adaptor that he wired the 2764 PGM* to VCC. That should work for reading. The difficulty here is that the 2564 has three lines that must be low to read the chip. The 2764 has two low, one high select. Without adding an inverter gate.. you can force the 2764's PGM* pin high, and choose 2 of 3 of the 2564's (S1*, S2*, PGM*) to connect to the 2764's (G*, E*) but you have to leave one unconnected! You can't short two of the 2564 pins together. It really depends on how the original board wired the 2564, as for which two you should pick. Maybe one is non-essential, maybe not! (EDIT: I see Ksarul did just short two pins together. IF this produces an OR function, great, if not, uhoh.) For something like an RS232 DSR, it might not even matter if you just short E* and G* to ground and PGM* to VCC, and let the EPROM drive the data bus all the time. Because the card should have a 74LS245 data bus transceiver on that. But if the card is a disk controller, it uses the DSR space to write and read to the controller chip too. So you really need to check how the card wired up S1* and S2* and PGM* to be sure what kind of adaptor you need. If you're lucky, S1* and S2* are shorted together, so your adaptor could pick either one. (I looked at Thierry's site, he doesn't have precise info on how the TI card ROMs are selected.) Unless I'm missing an easy way out of this, I think the answer is, you need to look at the schematic of the card in question to see how to build an adaptor. OR, you add a NOT gate to the adaptor; you can make one from a transistor and two resistors.

I’ve been unable to create a login on myti99. We tried to get a couple of TiPis on it at ATX but never got past the account creator.

When you use the R option, it’s as if the assembler inserts: R9 EQU 9 So your statement means CI R8,9 the assembler is just following simple orders, so it doesn’t see anything wrong. this kind of thing in modern practice should be a warning, maybe it is in xas99?

I gotta go with Extended Basic. So many hours, so many overnight Fridays with programmer friends, so many grand schemes to become a software megabuckionare. Even when I was toe-ing into Editor Assembler when I was 14, the point was to CALL LOAD that into Extended Basic. Beginner steps!

I can think of some silly things. Recognize what GPL program is running from cartridge. Cheat at Munch Man. Every 30 seconds, put one of the eaten energizer pills back on screen. Modify sprites in other ways in other games. However, though you could restore GRMWA, you can't restore VDPWA and something would go wrong if you interrupted a write. (Just like if you forgot and left LIMI 2 on during your writes, while INT1 did sprite automotion.) Maybe this would be limited to modifying PAD.

The 9918 though has composite video in, which means you need an external genlock and 9938 composite out. The Superimpose function on the 9938/9958/9990 is set up for the family to work together. You use an external RGB switch controlled digitally. I think that I build the circuit from p104 in the 9938 manual to genlock two of them. It seems easier to start with two 9938/58 than to use the 9918A video in. I guess 9918/9938 would use the same genlock circuit though with an LM1881 sync splitter. Interesting. I think I read that to superimpose 9958/9990, the V9990 must be run at the same horizontal dot rate. But if I read the the V9990 manual right, the incompatible modes are the 14.3 MHz external clock, overscan "panel" mode (for advertising or pachinko?), and the VGA mode (25.2 MHz clock in, 31.5kHz 640x480 out.) So I don't know the reason yet why the MSX Turbo R carts moved away from superimpose. Sure it's easier to build. I haven't come out of lurking on MSX forums to ask questions (and many of the threads are from 2007...) Today I'm building a plain 9958 prototype. Doing the research was fun, but it's time to build some stuff.

I was not aware of such a trick. Are you sure you remember that it was possible to cross a page boundary? There are only 8 bits in vertical scrolling register #23 so >FF is the limit. If you write >F8 then the display should take the last 8 rows from Page 0 rows 248-255, followed by Page 0 rows 0-183. For what you want to do, one way would be to set an interrupt on a particular line, then use the interrupt handler to change the page number in R#2 (manual says values are >3F and >7F for pages 0 and 1.) But that is surely not what you recall either... What do the other, undocumented values of R#2 do? If you put in >3E do you get something like what you describe? I'm taking a wild guess. I have not yet seen any "undocumented 9938" writeups. I found this nice annotated 9938 manual on GR8BIT http://rs.gr8bit.ru/Documentation/V9938-programmers-guide.pdf For one thing, explanation of R#23 in section 2.1.4 has color screenshots. My Geneve is still sitting here for lack of a working 5.25" floppy drive (of all the things).

I came back to this topic when I searched for V9990 info. By "reproduction V9990" do you mean the new carts? I read about original GFX 9000 that used a V9990 in the 90s. Now I see videos like this PowerGraph for MSX Turbo R which the poster says can only use a second monitor. They seem to have been made in small batches over the years as clones. Or did you mean there is a reproduction chip? I hope not, that sounds sketchy. I'm looking at the possibility of overlaying V9990 behind V9958, because V9958 has all the text modes and backwards compatibility, and V9990 has only new graphics modes. (including super fast font glyph copying, and unique Kanji ROM support, but still not text mode!) The only lead I have right now on V9990 is 50 pcs @ $24 each . The VRAM like MT42C4256Z turned out to be obtainable for a few bucks. (Aside: I had never seen a Z package. It is an idea that was made for routing PCB grids of memory chips.)

SO, the quotes I saw for V9990 at $2 and $10 were not actually real. I can get V9990 MOQ 50 at $24. That's how things are now. I found compatible VRAM MT42C4256Z or CZ or C is not hard to find (a few bucks). If someone wanted to go in on an order, I could see splitting up 50 pieces and VRAM.

The V9990 is available in quantity through alibaba.com sellers. You can get competing quotes: I got a range from $2 to $24. I'm ordering 100 for a upcoming TI-99/4A project using a V9958. It was going to be a twin 9958, superimposed. But adding a V9990 is much better, keeping the V9958 for compatibility, and the V9990 for power. Our chip progression goes TMS9918A -> V9938 -> V9958 (or an F18A if you can get one) The problem I'm having is finding the dual port VRAM for the V9990.

Geez... you do find everything! They were used some years ago to make a run of new carts for MSX2 Turbo R. I would love to overlay the V9990 on the V9958 - they have compatible superimpose mode (I think, if they are set to the same resolution.) The V9990 contains only the new modes planned for MSX3. Because V9978 was cancelled, and its V9958 core was pulled (licensing reasons) leaving the V9990 product. (Or so I have read on the forums.) I think that if you put the two chips together, you get something great. The V9990 has some crazy video modes, but reportedly 20x speed at block moves (a weak point of the V9938.) It's not backwards-compatible with V9938. See this V9990 review and this article List of known V9990 games on MSX Turbo R. EDIT: Well, dang, look at all these suppliers claiming to have new V9990 stock. I might just get a quote. Caveat: working with that 128-pin package terrifies me. And the answer is, V9990 is available from one seller at qty 50 @ $24 Another for qty 10 @ $10. Another for qty 50 @ $24. As for the dual-port VRAM required, I found some on eBay for $1.50 each I'm going to put V9990 on my list for 2021. The idea will be a V9958 superimposed on a V9990 because the V9990 has no text mode and no compatibility. Transparent pixels on the 9958 would show through to the V9990 video mode. I already made a schematic and board laid out for twin 9958 with a high-speed RGB switch, so... "Video cards" will be swappable on their connector, and on my prototype schematic/early layout (last week), there are 2 VDP select lines for 2 identical 9958 "cards". I'm only making one 9958 now though. I'm using IDE connectors (2x20) in the prototype backplane for an 8-bit bus, device select, port#, interrupts, etc. This bus prototype is set up for "cards" with up to 4 Yamaha chips (2 MSX-video, 2 MSX-audio) and an F18A carrier, all pluggable independently. So I could make, separate video card options at different times: V9958 only F18A carrier (please don't plug in a 9918A) on second monitor V9958 + V9958 on one or two monitors V9958 + V9990 on one monitor I'm really happy that an upgrade to the 9958 is possible. As one MSX owner wrote in 1995, upon getting the Graphics 9000 upgrade for their MSX Turbo R, "We're no longer stuck in 1985."

I just like the idea of real hardware to plug in. I think you said you preferred a machine in a PC case, so the module port would be irrelevant. I think the slot would be beneficial for people to load up their FinalGROM to move to a 4A, especially after developing. I'll make the final board fit inside a PC case form factor with a ports panel, but I'm building a standalone console for myself. Also on the topic of "real hardware". I'm whimsically making the memory 30-pin SIMM modules (which are still being sold new.) Anyone can plug in 2, 8, or 32MB (in pairs). Maybe 8MB will be standard.

Hi Beery, I really value your feedback. You are probably the #1 user to consider. Let me assure you that when I dream up new features, I'm still going to keep things compatible. I think breaking even one program that people expect to run, is too much. I'm probably going to fail that promise, but strive to offer a replacement. (like making a utility redundant with a built-in.) A key concept in operating system design is the Hardware Abstraction Layer, or HAL. HAL makes the hardware details invisible to the program that is running, making it think it's on the system it was written for. I'm working toward a HAL that MDOS will see as its native environment, with the goal of binary compatibility. As you said, being able to run the latest MDOS binary as a test. Getting the HAL right could mean two things. One way, the machine is custom-built to run MDOS exactly, and not use any features that are distinctive to the 99000 architecture. MDOS runs in supervisor mode, with a new boot EPROM to set things up. There might be a bit that puts it in a New Mode. (Like Geneve/GPL cru bit that changes the memory map for all the device ports in the Geneve 9640 gate array.) The other way is, the machine uses the 99000 to its full potential, and a Supervisor carefully sets things up (along with the FPGA) to run MDOS in a compatibility layer. This is analogous to going from from DOS to Windows XP. All the old applications are preserved, but "DOS" is no longer in full control. Direct hardware access can be intercepted, permission granted, and bytes forwarded. This is the interrupt and XOP model I described recently. It's actually easier to fix compatibility problems under this model. I'm interested in building a machine with the full potential of the 3rd generation 99000. I think that is much more exciting. It means using supervisor/user modes, allowing for multitasking between MDOS and something else. (For instance, another MDOS image, a debugger outside MDOS, a standalone GPL, and so much more.) The Geneve 9640 provides a HAL to the GPL environment by mapping devices into the addresses that GPL expects, and so on. My Supervisor would put MDOS into a 2MB address space of its own, with bank registers and the memory-mapped ports where MDOS expects. These things are mapped in the FPGA to the actual things. The FPGA would also recognize the Geneve/GPL mode bit change, and flip the port addresses within that 2MB space. That's a HAL: MDOS gets just what it expects. Keyboard Simulation All the keyboard inputs I've imagined, will be translated into one AT keyboard stream, and delivered to the port where MDOS expects them. Simultaneously, that will be mapped into a 8x8 keyscan matrix, that the 4A originally used. (That could be provided to GPL mode to make old KSCAN and all direct-keyboard access compatible again.) MDOS will just see a thing that looks like its gate array and key input port. This is done in the FPGA, which receives the keyboard stream from the 9995 coprocessor and queues it up. That's a HAL, and will make things "just work". As a bonus, the keyboard input could also be from the high-speed serial port, which might allow remote access. At the same time, I'd like to make GPL more compatible than even the Geneve 9640 offered. To do that, more HAL under GPL mode. Like adding back the 8x8 keyboard matrix. Under GPL mode, the 9901 could look exactly like it did in the 4A, keyboard lines and all. I want to re-fix the issues with VDP registers reserved bits being trashed (some GPL programs were patched to fix this.). This would be done in the FPGA, which forwards all the VDP ports. (There might be some logical contradictions with restoring the 9901 in GPL. I don't know if any programs were written for GPL that also peeked at the Geneve-specific CRU bits? Like, checking the bit for whether a keycode was ready, or left mouse button. Also, the TI ROMs are already patched for KSCAN. So maybe the "more compatible GPL" will have to wait for a "New standalone GPL" program. I imagine a New GPL that just takes the original ROMs.) Breaking Mouse Functions A big difference between V9938 and V9958 is that the mouse/lightpen is gone from the VDP. So there must be a new mouse interface, from the PS/2 mouse through the 9995 I/O coprocessor and the FPGA. The logical way to work with this is to write a new XOP for GetMouse* functions, residing in the Supervisor EPROM. (As a refresher: in the 99000, Supervisor gets first look at any interrupt, XOP or LIMI call, and can handle them itself, or forward them on to the User task.) The Supervisor can take the XOPs for GetMouse* , do the job itself, then return to the caller--no changes to the MDOS binary. Another piece of this puzzle is in the VDP interrupt handler. The code in MDOS VX-INTS does sprite motion, sound duration, and mouse updating. It polls the VDP mouse registers for X and Y and middle/right buttons, and tests the CRU bit for the left button. The logical way to work around this is to put a new interrupt handler in the Supervisor. It would rewrite the handler entirely, ignoring the code in MDOS. Another way is to branch to the original handler, let it do its job (including reading the empty VDP mouse registers), followed by the Supervisor tacking on the real mouse updates. The end effect has to be that the TRUEX and TRUEY, button bits, and other variables get updated the way MDOS expects. (Aside: the interrupt handler, and the MDOS API, has dreadful sound support.) I think the mouse behavior is going to work. UNLESS there are some applications that try to read the VDP mouse registers themselves (or the left mouse button CRU bit). I'm not really excited about providing a HAL for deleted VDP functions. It means having the FPGA intercept reads of some VDP registers to mimic the old behavior. It's possible? but I'm not thrilled to have to do it, unless the effort provides something new and great. Other V9958 differences besides mouse V9958 drops composite video (does anyone want an encoder added back in?) It has a horizontal scrolling register (yay!). No lightpen/mouse interface. It has a version detect bit. It adds a crazy new YJK color mode with 15-bit RGB colors. Superimpose and external sync are more robust. Most important, V9958 is easy to get for $8. Otherwise it is close to the V9938. (Aside: V9978 and V9990 are nonexistent and unobtainium.) Summary I'm aiming to use the full potential of the 99000 architecture while not breaking any Geneve software. As Beery said, running an unmodified MDOS binary should be the test it has to meet.

I was really interested in reading about them, because I'd never known about their history as a real-time clock, but, I doubt I would have a use for the actual chips. When you posted first, I read the datasheet. I really appreciated that you brought them up. It's fascinating that this is a socket that goes underneath a RAM chip with a clock hidden inside, and keeps the RAM backed up by battery. NVRAMs still cost a lot of money, and replacements for $20 are used in pinball machines. New stock DS1216s cost $10-$20 still. I went on surveying RTC chips , looking for one to use in Geneve2020. Because the RTC used in the Geneve is also obsolete (like the Dallas chips) work-alikes also cost $20. Eventually I found a good solution, a new chip that costs $1.50, after looking at 5 chips in detail. So.. thanks for offering these, I got a lot of knowledge out of it, but you might find a cash buyer, by offering them on eBay.

for me, it's still showing the Malware error. As long as you've got it preserved!

Adapting MDOS, XOPs, and Interrupts I did a read-through of the MDOS 6.50 source code and API, looking for code that must change for the TMS99105. It includes rewriting the XOP entry code. But that's ok. First: On the TMS99105, there is Supervisor mode (call it SUPER) and User mode (USER). Geneve2020 will have an 128K EPROM-based kernel that runs as SUPER with a private Static RAM, while MDOS runs as a USER application in main RAM. Second, some TMS99105 instructions can only execute in SUPER. If the USER application tries to execute them, the SUPER takes over and decides what to do. These include LIMI, XOP, and LST; also, all interrupts. Whenever the SUPER takes over, the entire memory map is switched to its private EPROM and RAM. The MDOS APIs are implemented as XOPs. This means that the XOPs all go over to SUPER, which decides whether to run a new version as SUPER (for instance: memory management), or branch to USER's copy of the XOP (for instance: math). New versions of XOPs, that run as SUPER, are rewritten to access USER memory for registers and data. LIMI 0 will be simulated in SUPER, which continues to get all interrupts first. SUPER checks if the USER application is ready to handle the interrupt now or later. I'm aiming for 100% binary compatibility. To that end, if you boot an existing build of MDOS, the APIs will just work, because all of the XOPs will branch into patches in SUPER code instead of the original MDOS. Unfortunately that means that if you run an older MDOS build, it could get patched to the latest greatest XOP (bug fixes and all.) Oh no? As an additional perk, I foresee having more than one MDOS instance loaded simultaneously, each with its own 2MB slice of memory, and a key to switch between them. XOP Flowchart SUPER runs the USER application USER application has its XOP table in RAM at >0040 USER application tries an XOP SUPER takes over, vectors through its XOP table in EPROM SUPER decides how to handle the XOP Case 1: SUPER runs a new implementation of the XOP in its EPROM, retrieves registers and data from USER, writes results Case 2: SUPER branches through the USER XOP table INTERRUPT Flowchart SUPER sets the interrupt mask in the Status Register to take all interrupts (say LIMI 4) SUPER runs the USER application, marking its application interrupt mask to 2, but not changing the actual Status Register. Case 1: an INTx comes in (RESET, INT1, INT4, NMI, etc) TMS99110: SUPER takes over and branches to SUPER INTx vector Execute any SUPER handling for this interrupt If USER application mask >= actual INT level, Mark interrupt as handled in USER Branch through appropriate USER interrupt vector, but set up USER registers for RTWP back to where USER was interrupted. USER does its interrupt routine USER RTWP goes back to where USER was interrupted. Else Mark a pending INT in the USER table. Return to USER where it was interrupted. Case 2: USER makes a LIMI call SUPER updates the USER interrupt mask, not the actual Status Register. If there is a pending interrupt, go to Case 1 Else return to USER Benefits Your MDOS disk images can boot and just work You could switch between more than one MDOS instance in memory If MDOS crashes, the SUPER is still there to help you recover MDOS doesn't prevent SUPER from getting important interrupts

Yeah, I could not get Gazoo's hard disk image, part 1 zip file, Yahoo says it's got malware (which is surely false) Otherwise I have a dump of all the other files + whtech. I also downloaded your message base dump and read a bunch of it. Thanks for covering this! I'm cataloging all the known Geneve software, for use in testing (and my enjoyment). I'll post my catalog on the Geneve Software thread, for review and further additions.