FarmerPotato
-
Content Count
1,464 -
Joined
-
Last visited
Posts posted by FarmerPotato
-
-
21 minutes ago, jedimatt42 said:Are all of the enables good? one is supposed to be active-high.
High 10k pull-ups on the outputs might help. After doing, that, removing the '138, do you still get erratic values at the pull-up point? caused maybe by the downstream circuit?
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-
1
-
6 hours ago, FarmerPotato said: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!
5 hours ago, pixelpedant said:I doubt I'm the only one around here. I know there are folks around here using a Geneve with a 15KHz RGB solution. But in the broader community, 15KHz RGB is standard on MSX2 and Atari ST and CoCo 3 and a bunch else. So it's not like nobody's using 15KHz RGB monitors in their computing on 80s-era hardware.
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.
-
2
-
1
-
-
2 hours ago, pixelpedant said:I suppose one thing I'd like is a 9918A replacement with 15KHz RGBS output as at least an option. I downscale the F18A's 31KHz output to 15KHz for use with my 15KHz RGB monitor. But it's not perfect. It'd be nice if it were generated as 15KHz. So I guess that would still be a wishlist item.
Another I suppose is a replacement keyboard PCB, so a bunch of us can get to tinkering with building keyboard replacements. I think that'd be a really fun project. Figuring out what the best solution is for custom caps, maybe arranging a group buy, and digging into an esoteric custom keyboard build project with some unusual geometry.
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!
-
1
-
-
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.
-
3
-
-
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.
-
30 minutes ago, RXB said:But now that Apple is going full on ARM chips I have no idea if in future you could even run Windows anymore at all on Mac.
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).
-
18 hours ago, Omega-TI said:I just received six more beige cartridges to retask for UberGROM boards. Normally I throw away the internals, but this time one of them seems like it might be a keeper. Anyway the cartridges I received are:
Fractional Numbers
Meteor Multiplication
Jawbreaker II
Alligator Mix
Football
Adventure
The last one, the Adventure module seems like it might be work keeping. Does anyone have any input on this one? If it's worth keeping I'll hunt for a manual and I assume some 'adventures'. Who knows, someday I may have the time to try it out.
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.
-
1
-
-
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/QuoteCorrection: December 4, 2020
The original version of this article incorrectly reported the newly measured value of alpha as 1/137.03599920611; the correct number is 1/137.035999206, with an uncertainty of 0.000000011. In an article about the “nailing down” of the constant’s value, we regret the error.
137.03599920611 printed 137.035999206 new actual .000000011 new uncertainty i.e. 137.035999206 +/- .000000011-
2
-
1
-
-
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.
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-
1
-
-
2 hours ago, pixelpedant said:That'd be awesome, Lee. I figure the buffered one's the one I'd use the most. But it sure doesn't hurt to have options!
I suppose on reflection it's not surprising that this doesn't exist somewhere as just a support routine sitting on a disk for some relatively elaborate legacy XB program (like the XB RPGs).
My thinking being that the current appeal of speeding things up or simplifying matters by just dumping large chunks of pregenerated sprite/screen/pattern/colour data into relevant VDP locations as bytes is substantially contingent on two things, neither of which is true in an 80s context: namely, disk access is fast and convenient, and storage is arbitrarily large. And more importantly, handling and generating assets as VDP RAM dumps is easy, and is supported by various cross-platform development tools. Such that it's tempting to just "cut out the middle man" as far as some of that data goes, even when using XB for the broader program logic.
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!
-
4 hours ago, InsaneMultitasker said:Here's a site I saved along the way that may be of interest. The first few pictures of the sockets represent what I have found along the way in many of the cards I repaired - whether logic, ram, or EPROM - and often times the low height coupled with age tends to lead to sporadic connections with the chips. Not all of them are problematic though certainly a good thing to keep in the rework/troubleshooting arsenal. (the comment about new chips flaring outward is something that caught my attention back then as well)
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.
-
3
-
-
1 hour ago, webdeck said:I connected a new switch with a 220 ohm resistor and it is working. Thanks!
Hooray!
-
1
-
-
1 hour ago, atrax27407 said:I just finished an "all nighter" trying to find another equivalent for the AT29C040 and AT29C040A. There is NO functional equivalent among multiple manufacturers for the AT29C040. The ONLY equivalent for the AT29C040A is the Winbond W29C040 and it is exact. So, unless you check for the manufacturer/product ID in the programming algorithm, you could most likely get by by eliminating it completely. Just use either the W29C040 or the AT29C040A. A single programming algorithm would work for both.
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.
-
23 minutes ago, atrax27407 said:I mailed out some to him this morning.
Uh. I just sent him 4 and 5. @Shift838 will be set for a while.
-
1
-
-
3 hours ago, mizapf said:No, I think this referred to some bits in the video registers of the TMS9918/28/29 (NTSC or PAL) that were unused, and which now have a meaning with the V9938.
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.)
6 hours ago, MueThor said:V9938 is backwards compatible with TMS9918 so yes it will work properly. Sadly it won't work with the VRAM chips the TMS9929 you have uses. It need 4416/4464 (4bit) RAMs and may not work correctly with 1 bit DRAMS on the wiring required by the TMS9918/28/29.
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.
6 hours ago, MueThor said:I want to connect it to a PAL modulator.
I didn't know that V9938s are harder to come by than V9958s. Would a V9958 also work with only 16k VRAM?
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?
6 hours ago, MueThor said:Now, if there is a way to realize a V9938 and/or V9958 minimal upgrade, can anyone of you give me an instruction and schematic drawings for the realization of such an upgrade?
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.-
2
-
-
5 hours ago, MueThor said:Hi folks,
Can anyone of you help me with an instruction and/or technical respectively circuit drawings for a simple as possible hardware replacement of a TMS9928A with a V9938 in the console of a TI-99/4A? Of course with retention of the 16k VRAM (yes, I know that you can address up to 192k VRAM with the V9938) originally implemented in this console, with as few as possible additions of extra ICs and modifications to already existing ICs.
Regards
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
-
1
-
-
I guess you will try breadboard first? Have you used wire-wrap?
My favorite sources for ICs and surplus
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=homeLike 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/4547042or 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/
-
1
-
-
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.
-
3
-
-
39 minutes ago, Kchula-Rrit said:It's a terrible title, but I could not think of a better one.
I'm getting ready to build some add-on hardware for my TI99, so I dialed-up the Digi-Key Web-site. They have an alphabet soup of part numbers (they call it "series") for logic gates and such. For example, I was looking for a 7432, which is a 2-input OR gate with four of them in a 14-pin DIP package. If I recall correctly, the options I found were
7432
74LS32
74S32
74HCT32
74AS32
74ALS32
74ABT32
74F32
74ACT32
74ACTQ32
74AHCT32
74ABT32
The first three I've used when I built computers, back in the 1980s, and I'd heard of 74HCT parts but never used them. The 'good old' 74LS32 is a lot pricier (~ $1.10) than all the others, except for the plain 7432 (~ 2.40!). Tentatively, I'm going with the 74HCT family, as I remember it is supposedly TTL compatible.
Would that be the best choice, or should I bite the bullet and go for LS parts? I'm thinking of logic levels, drive capability, speed, etc. Advice from more knowledgeable (and less "rusty") folks is much appreciated.
K-R.
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.-
2
-
-
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.
-
2
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Bringing up "Geneve 2020": Debugging Help Please!
in TI-99/4A Development
Posted
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.