FarmerPotato

I removed the 9902 which sinks Y2* into its chip select. Here the red trace is the Y2* output of the '138, yellow is the G2A* input which is driven by bus signal SERENA*. They are unusually noisy. This capture is during a TB 27 instruction. BST is bus status from the 99105 (B indicates a CRU cycle) AD is address/data, you only see the address just after ALATCH* goes low. (LSB of an address is CRUOUT, not part of the 16-bit address) The address 13B7 (really 13B6) is the CRU address of a TB 27 instruction. CLKOUT is 3MHz RDBENA* is the direction of the backplane data bus WE*, RD* are the read and write strobe INTA well thats interrupt acknowledge seen right after RESET SERENA* indicates a CRU cycle. CRU... is the CRUOUT line.

The bad '138, the enables are all stuck high (tested bad on breadboard, outputs stuck high when in the board.) A good '138 (tested on breadboard) becomes erratic in the board. Enable outputs are ~2.5V, especially the G2A* input pulls SERENA* to ~2.5V (SERENA* is the output from a '645 driver and indicates a CRU cycle.) (I use '645 drivers for both the '244 and '245 roles.) Removing the '138 or leaving in the bad one, there is no interference with the bus signals like SERENA*.

Trying to debug serial I/O. I'm using the AdaFruit FTDI Friend 5V, between the PC and the 9902 (just 0-5V levels. No MAX232 yet.) First I got familiar with logic analyzer capturing bits from the PC TX. 2400 bps, 8N1. Starting off slow. On my board, tiny3.a99 test program initializes the 9902 at >1380. I observed all the CRU operations to load the rate registers etc. I'm confident that all is well on the software side. Logic analyzer captures show it doing all the right things. Problem is, the 9902 chip select doesn't seem to assert. My CRU decoder is an LS138. One of the enables (G2A*) is my SERENA* signal which indicates CRU access. The other 5 inputs are some address bits. Y2* out decodes base >1380 and goes to the 9902 chip enable. I can see all the proper inputs but no Y2*... I tried replacing the LS138 and got wackier results. Suddenly, the new LS138 is sucking the SERENA* signal down to 2.5V! That's messing with a '645 driver output from the CPU board. Is it really sinking enough current to screw up the driver? Naturally all the outputs are ~2.5V too. I tested all my LS138 on a breadboard. The original has no Y2* low output, all outputs are always high regardless of ABC inputs. It has been in my board for a lot of test cycles, and it is definitely bad. The other chips test good. So, bad LS138 chip, stable behavior but all outputs high (wrong). Good LS138 chip, erratic behavior and even the inputs get screwed up. Also, a separate LS138 is working as a memory space decoder--no issues there. I checked every socket pin for shorts.. at least at the bottom of the socket. The first couple LS138 were Fairchild. The first one of those is now bad. All the good chips act erratically, Fairchild and TI brand, plus one TI HCT138. Mostly from Unicorn Electronics. Maybe the 9902 is bad, and the chip enable is a short. Or worse, not a real 9902... Ideas? Remove the 9902 and check the LS138 alone. Check whether the chip's pins are really making contact? (bad socket) Re-check all the wires to the LS138 to see if any of them go to dumb places. Vacuum the boards looking for stray bits of metal. Go over the board with a microscope looking for bad connections. Here's a snapshot of some CRU activity. The code. First SERENA* assert is for the sbo 12. li r12,>1380 sbo 14 load control register li r0,>8B00 8N1 ldcr r0,8 * begin screen capture sbo 12 skip interval reg, go to reception reg li r0,>009c 2400 ldcr r0,11 reception rate register ldcr r0,11 emission rate register

Oh for sure. I have the versatile MP910 for my F18A and Geneve (SCART). It's just funny to me since folks are eager to get an F18A solution to use current LCDs, while you want the F18A to downscale to 15kHz RGB. I agree there should be a plug-in 9958 solution for those who have/want RGB out.

Wow, 15kHz RGBs are hard enough to obtain. Upscaling to VGA gets us all the LCDs. You must be the one person who wants to go the analog direction!

The drawing block is so similar it could be factored. You could have an array of 2 elements, space and gate-char. The first to be emitted adds the odd-even index. The second to be emitted adds the 1-the index.

Hmm, the XB manual indicates that this opens the file with defaults SEQUENTIAL, DISPLAY, and UPDATE. This should be non-destructive until you PRINT #1. I made a 1-record file in TI BASIC and ran the above. I got the same result in BASIC or XB right after that. So I'm not sure what's going on with your program? Is it really there when you run it in XB? If you don't intend to change the file, you should open it as INPUT. I've only used UPDATE when I also use RELATIVE and INPUT #1,REC X:A$ PRINT #1,REC X:A$ and so on. Having a file open with UPDATE and SEQUENTIAL is awkward. You can input a record, but print over the next record. You can RESTORE #1 to the start of the file to rewrite it I guess. It's been 30+ years since I wrote any XB so I could be missing something.

Yes, you can. https://9to5mac.com/2020/11/20/windows-can-run-natively-m1-macs-apple-silicon/ The Apple Silicon M1 makes the MacBook essentially the ARM architecture which the Microsoft Surface Pro has. As such, it can run the developer version of Windows for ARM just fine. And that includes x86 emulation. From the reviews so far, performance is quite good. But highest performance is seen from Windows apps that have been re-released in builds for Surface Pro. This still depends on Microsoft allowing consumers to install Windows for ARM. Two other solutions will be CrossOver and Parallels. Both are x86 emulation on ARM and will run Win32 apps if not the whole Windows OS. Parallels solved this problem during the PowerPC era of Macs. It's going to do it again on Apple M1. I have two identical MacBook Pros, which run Windows 10 (Boot Camp) and Mac OS X. Different uses. There is a lot of open source software that runs perfectly on Linux and Mac OS X, but badly or not at all on Windows. Even under an environment like Cygwin, which makes Windows more Unix-like. Several other free packages, which for me includes Kicad, OpenSCAD and FreeCAD, are cross-platform. Those run on Mac OS X Windows 7 and Windows 10 natively. They should appear native on ARM quickly (anybody can recompile them).

I have an affectionate spot for Alligator Mix and I don't currently have one. I would happily trade beige Home Financial Decisions or the like, for edu cartridges, before they are scrapped.

When a correction is issued, it isn't usually this meta: Physics' fine structure constant, alpha, is measured to new accuracy: https://www.quantamagazine.org/physicists-measure-the-magic-fine-structure-constant-20201202/ 137.03599920611 printed 137.035999206 new actual .000000011 new uncertainty i.e. 137.035999206 +/- .000000011

This is some code I wrote to do the job. In 1988. It is mixed in with some 9938 command code for LINE and PSET and all the graphics modes including 80 column. I don't think XB likes that. But here is XB CALL LINK("WRITE", vaddr, string$). There is also a FILL in there. I can't test it right now. The key source. If there are undefineds, I have attached the whole file. xbs DEF WRITE FAC EQU >834A XMLLNK EQU >2018 CFI EQU >12B8 NUMASG EQU >2008 NUMREF EQU >200C STRASG EQU >2010 STRREF EQU >2014 VDPRD EQU >8800 VDPSTA EQU >8802 VDPWD EQU >8C00 VDPWA EQU >8C02 * CALL LINK("WRITE", vaddr, string) WRITE LIMI 0 MOV R11,R12 * Get argument 1, a number LI R1,1 BL @GET MOV R0,R3 * Get argument 2, a string BL @GET$ MOV R2,R2 JEQ WRT MOV R3,R0 BLWP @VMBW WRT BL @SETB0 B *R12 * STRREF, R1=STRBUF R2=LEN GET$ CLR R0 LI R2,STRBUF SETO *R2 BLWP @STRREF MOV R2,R1 MOVB *R1+,R2 SRL R2,8 RT GET CLR R0 BLWP @NUMREF BLWP @XMLLNK DATA CFI MOV @FAC,R0 INC R1 RT VMBW DATA VWS,V4 V4 LIMI 0 MOV *R13,R0 BL @WRV MOV @2(R13),R1 MOV @4(R13),R2 JEQ V4X V4A MOVB *R1+,@VDPWD DEC R2 JNE V4A V4X RTWP VWTR DATA VWS,V5 V5 LIMI 0 MOV *R13,R0 ORI R0,>8000 SWPB R0 MOVB R0,@VDPWA SWPB R0 MOVB R0,@VDPWA RTWP SETB0 LI R0,>0E00 BLWP @VWTR RT

I agree with considering what is 80s spirit (even if you run it on emulation). I think your issues can be reasonably addressed. It comes down to how much data and how often? Load from disk Give yourself a budget of 90K of assets as a minimum. Also compress it! Let the assembly routine unpack it. Require just a few records of data for each update in the game. Cache the most recently used (maybe just 2 screens worth.) 90K is enough for a hundred screenshots (in chars), a couple of charsets (48-64 characters each). The killer is text. At one extreme, an Infocom data file takes the whole disk. TI-Runner periodically loads 1 screen from disk (albeit from all assembly.) Loading a screenful of chars from strings is reasonable: 6 records of DF128, less with RLE compression. I used this technique to initialize screen data into a 4K buffer in low RAM, 8 screens for a level, each 16x32. One assembly routine to blit a section to the screen. Initializing your charset is another: one DF128 record is 16 char definitions. Rule out loading a full bitmap picture. It's beyond XB VDP capacity. Data hiding Put the data into your program to make it faster. Hiding it in the 24K RAM as lines, locatable only by routines aware of it. I'm rusty on this technique. But I think you load your data into 24K, change the first free address, then MERGE the XB program. Then at runtime, your assembly routines can grab from it. Barry Boone's SYSTEX was one example of this technique (it creates a program in the 24K, that hides your 8K, and restores it the next time you run.) Uses For an RPG, assume you update the charset infrequently (like entering new terrain.) Then suppose a screen is static and composed of tiles. Say you want to fill 2/3 of the screen with map. It's 512 bytes or four records of chars. If you have 2x2 tiles, then only 128 bytes are needed to fill the screen. My first XB-assembly hybrid was a routine that took 81 bytes from a XB string and drew a 9x9 map of 2x2 tiles. I was pretty happy with that (when it was debugged...) If you have a list of bigger objects to draw, you can compose it of 3 byte chunks for row, column, object number. I'm talking about loading compressed data in pieces, not always a VDP dump. (Tunnels of Doom has the whole VDP image in its 52K: pattern table, colors, + data.) When you are comfortable with DSRLNK in assembly, move the loading (and saving!) out of XB code for another big speedup. Sprites Another technique I used is to store the sprite attribute table in low RAM. XB program updates a sprite location in a buffer with CALL LOAD(9472+S*4,Y,X) instead of CALL LOCATE(#S,Y,X). Pattern and color too. One CALL LINK("SPTBL") copies the whole thing to VDP. Instantly updated positions and frames. Combine same technique for the motion table. A substitute for turning the sprite motion bit off, looping across CALL MOTION, turning motion back on.. the assembly routine can set all the sprite attributes together. Code I doubt I can find any of my code for these things. So. It requires knowledge of XB argument processing, which is harder than VDP access. Hope this adds to the idea pool!

Ha! That was the first google hit I got using my phone. It's much better looking now that I am at my desktop. Thanks for posting that. Lot of practical experience there. The single wipes that I have are wire-wrap, some of them reused! The new ones of those are machined-pin, which I hate. There's only one example of the boxed up (double-wipe) on page 2 here: https://www.peconnectors.com/sockets-wire-wrap/

@InsaneMultitaskermade a comment that he replaces single wipe sockets with double wipe. I think most low profile open sockets are not single wipe. I never knew about this before. are your sockets machine pin holes or the springy contact kind? I read elsewhere that corrosion in the pins bends the contacts so new chips don’t make good contact. Folks recommend machine pin sockets. I hate those because it is hard to get a 32 DIP into one without bending a pin. I am going to pay more attention to the socket contacts in future.

Hooray!

I'd like to hear what you found. Sector size, Are the programming commands different? What differences are there in the super common chips? Are there schematics for the PFM? If it is just the Flash chip, there's that adaptor for the TL866/Xgpro. Also, I could easily make a PLCC adaptor board. I made one for a breadboard, using through-hole PLCC socket.

Uh. I just sent him 4 and 5. @Shift838 will be set for a while.

What he said. Programs run on a 9918/9928/9929, but break when you have a 9938. For instance in VR#0, the TMS9918/28/29 (no differences in what follows). TI defined the lower 2 bits and the data book says to make the rest 0. If software puts random values instead, it puts the 9938 in the wrong video mode. Same deal in VR#1. (It goes both ways: the bit for 4K/16K DRAM addressing is supposed to be kept at 1 for the 4A and the 9938 data book says to set it to 1 always. If you make that mistake and test only on your 9938 system: oops.) Not sure who wrote this up there, but I'm curious what the answer turns out to be. Ugh, it doesn't work: I checked the V9938 data manual and it shows a configuration with 8x16K on page 137. It shows the data-in and data-out pins wired together, to the V9938 data bus. I checked the TMS4116 data sheet and I don't see a problem with wiring them together. I checked the TMS9918 data book and, oh right, it doesn't work that way. The TMS9918 has an address/data out bus, and a data-in bus. The AD is an output still, while the data is read, so, that's why it can't work. The 4A board is hard-wired for that. On the other hand, TMS4416/4464 have a unified data-I/O pin, and the V9938 works that way. I don't see in the 9958 addendum that that has changed, but it is now moot. I have no experience with PAL or PAL modulators. Just NTSC At http://www.nouspikel.com/ti99/titechpages.htm the PAL cable pinout is: # Use - ----- 1 12V vid 2 R-Y (color burst clock) 3 Sound output 4 Y 5 B-Y (external video input?) U GND The 9938 does not output Y, R-Y, B-Y (aka YPbPr) like the 9928/9. However, a chip like CXA2075 can give you RGB, Y+C (S-video) or composite PAL. Would that help? (This is the PlayStation 2 video encoder.) Otherwise an SCART-Genie type box would be a good option. What inputs do you have on your monitors or TV? That's still a lot of work. There are a lot of untested schematics floating around the Internet. I hesitate to add one more. My 9958 project schematic, which is not working, is here https://gitlab.com/FarmerPotato/geneve2020/-/tree/master/kicad/vdp I answered because, adapting it to a 4A console is still on my horizon.

I have lots. Just PM me your address again.

It seems like we have 23 respondents and 8 Geneve owners so far. That’s making all the percentages low. what’s a PFM for those who don’t know? I’m sure I don’t have one. also I have one Geneve with 32K RAM upgrade and one without. HFDC and TIPI.

That's an interesting idea! We've seen 9938s and 58s as part of an all-out upgrade, but not a minimal upgrade. Memory 16K chips address as 7,7 row/col while 64K are 8,8 row/col. The V9938 technical manual shows a 16K configuration. The most significant address bit is not connected. There is a bit in VR#8 that selects 16K on 0 or 64K on 1, so that must cause it to emit 7,7. Without that, you'd be getting 6,8 and 1 bit would be dropped. You'd have to hope that bit gets cleared to 0 on reset. I don't see anything in the manual about what video modes work in 16K, but I guess it is the usual ones and maybe 80 column. Sprite mode 2 maybe. It is really not hard to add 2 or 4 TMS4464 chips to get the full memory. They up less space than the 8 TMS4116 in the console and only require 5V. Video Output The V9938 outputs RGB, composite video, CSYNC and HSYNC. The 9928 has Y, R-Y, B-Y (I will call it YPbPr) Getting the video signal to the back port--what do you want to connect it to? Maybe all you want is to output RGB? To interface to an SCART port, you need a sync stripper to output VSYNC. @Shift838 made the SCART-Genie that does that. It is a board with SCART out port, a LM1881 sync stripper, and a 8-pin DIN input (with pinout for the Geneve 9640.) Incorporating the LM1881 and some amplifiers adds very little space to a V9938 board. Going from 9928A to 9938, you lose the YPbPr output. I would try a chip like the CXA1645 or CXA2075 from MSX land. It takes the V9938 RGB in, outputs RGB, composite, and Y/C (Svideo). It has a PAL/NTSC switch. A better documented chip is the AD724. I not familiar with a YPbPr encoder. Software The V9938 has a bit in VR#9 for NTSC or PAL. It probably defaults to NTSC. To get PAL, you would need software to set this bit. If you use FinalGROM all the time, you could have some code that executes at startup. You would have well-known issues with programs that behave badly toward the unused bits in the 9928, with bad effects on the 9938. These have been identified and fixed in some copies. Cost $8 substitute V9958, the V9938 are harder to come by $1 each TMS4464 (use 2-6 chips for 64K-192K) $1 CXA1645 (DIP) or CXA2075 encoder (surface mount SOIC-16) $1 LM1881 (surface mount SOIC-8) Sockets - you need a V9938 shrink-DIP64. Not too hard to get. $20 PCB (wild guess, in small quantity) alternates $15 AD724 (new) but cheaper from surplus all these can be found on eBay or aliexpress

I guess you will try breadboard first? Have you used wire-wrap? My favorite sources for ICs and surplus https://www.mouser.com/ Phoenix has a great website. In PEConnectors it is easy to find that component you don't know the name for. https://www.peconnectors.com/index.php?p=home Like atrax27407 said, our friend at Unicorn has always stocked good parts, which we usually need for kit builds. https://www.unicornelectronics.com/ Great new stuff. Get their specials email: https://www.goldmine-elec-products.com/ Hard to browse, big junk pile, but tons of TI logic chips. https://www.electronicsurplus.com/ I'm a Mouser guy rather than Digi-Key, because I get amazing next-day delivery from Mouser Ft Worth. Also SparkFun, AdaFruit, Jameco. Source for 4A side port connectors Ksarul or I can probably share if you just want one. https://www.digikey.com/en/products/detail/hirose-electric-co-ltd/CR22A-44D-2-54DSA-70/5148616 https://www.digikey.com/en/products/detail/sullins-connector-solutions/ECC22DRMN/4547042 or just build onto a JediMatt42 TiPi style (I can't find 44 pin, but here's 40 pin long) https://www.peconnectors.com/female-headers-pcb-2x-row-.100/hws16501/

Continuing "tiny2 test" INTA (acknowledge) pin asserts on bus state 5 (INTA) SERENA pin asserts on bus state B (IO) On RESET, clear LED with SBZ 0 String copy to RAM "Hello World!" Compare string in ROM and RAM If good, turn on LED with SBO 0 Then JMP $ NMI button works, code turns on LED with SBO 1, returns with RTWP Tests run 100 times with same outcome All tests pass! This concludes tiny2 test.

You missed some families 🙂 LS or HCT or a mixture will be fine. If you compare the speeds, you may find that some LS devices have an edge. but it’s unlikely to matter in the 4A. You should download all the data sheets for parts you want, and look up some things to compare. Like the A/C switching characteristics: time to propagate input to output. when you make that table for yourself you may find that some parts between two families don’t follow the general rule. Maybe because they are a revised, improved version. if speed matters, check for an ALS part. If speed really matters, consider a PLD like a 22V10 which will smush down the time to evaluate a complex expression. Also calculate how many loads an output can drive. You shouldn’t run into any problems but knowing is part of the design. Eventually you will want to use a 3.3V part. These can be interfaced using LVC245A which are 3.3V but accept 5V inputs. LVC parts output a high voltage which is still above the Voh minimum for LS. The LVC125 is another to consider. TI.com has some guides like Designing With Logic. try those.

Hobby time has been scarcer lately, but here's a small update. I've changed the crystal to 3MHz, and now the RAM is working fine. So it was just a matter of my RAM being too slow for a 6MHz machine. Going to stay at 3MHz for the time being as it makes testing easier. Last night, I scrutinized every bus cycle of my tiny2 test program, all good. So encouraging. Tiny2 test used workspace registers, turns CRU bits on (At 6MHz, R12 was failing to read back from RAM) and copies a string from ROM to RAM. I verified each cycle through the logic analyzer. It's tougher because it doesn't capture the whole run at once. But it's repeatable every time, so I just specify microseconds-after-RESET to capture what I want to look at. It ends up in a JMP $ waiting for an interrupt, which I haven't tested yet. I need to make NMI a de-bounced button. Bouncing interrupts suck. Then the front button de-bouncer panel, I re-soldered as a cabled module. In crimping cables, I've graduated from "sucks less" to "finally adequate". Oh yeah, the green lighted power switch, picoPSU, ATX power distribution board, and quiet server fan are installed, and work great. Love that physical feedback. The PCB mounting holes were not usable (partly, because PCB mouse nibbles hurt the exact fit.) I just need to re-cut some plastic--not a priority. (Electronics Goldmine had this box of 24 super-slim server fans for $12!) A 9902 is attached and wired into a USB adaptor cable, so the next, tiny3 test program, will be serial port test code.