FarmerPotato

Thanks for your understanding. I goofed up and posted a src odd, dst even copy. The first MOVB aligns the source pointer to even, while caching the first byte. I see that it gives the same result whether src is odd or even. But if dst is odd, the result is even. My test code was: li src,>a001 li dst,>b000 li r2,>400 bl @copy

I did a cycle analysis of 4 versions of the inner loop. Assume the source is even the dest is odd. Assume registers and code are in PAD (no wait state) and data is in expansion memory or cartridge. MOV MOV4 MOVB MOVB4 ALU 48 43 13 34 PAD 40 37 9 24 MEM 8 8 3 12 Cycles 240 224 68 212 per byte 60 56 68 53 where Cycles = 2*ALU + 2*PAD + (2+W)*MEM MOVB4 wins I did not realize that even MOV does read-before-write. The source and destination evaluation work the same--both do a read from the effective address. Code MOVB loop: movb *r0+,*r1+ dec r2 jne loop MOVB x4, loop unrolled 4 times loop: movb *r0+,*r1+ movb *r0+,*r1+ movb *r0+,*r1+ movb *r0+,*r1+ ai r2,-4 jne loop MOV copy: * cache first byte movb *src+,r3 loop: * fill two src words: * grab a word mov *src+,r4 movb r4,@r3lb mov r3,*dst+ dect cnt jeq done swpb r4 * grab a word mov *src+,r3 movb r3,@r4lb mov r4,*dst+ swpb r3 dect cnt jne loop done: MOV4 copy: * cache first byte movb *src+,r3 loop: * fill two src words: * grab a word mov *src+,r4 movb r4,@r3lb mov r3,*dst+ swpb r4 * grab a word mov *src+,r3 movb r3,@r4lb mov r4,*dst+ swpb r3 ai r2,-4 jne loop done: To see all the equates and stuff, open the attached file. copy.a99

Thanks for posting, I didn’t know about this. Still some good stuff coming up this afternoon.

It would have been interesting if Commodore had been able to get 20 million Amigas in circulation, like the C-64. Licensing the platform? By the time PC multimedia had caught up, all the parts to clone video and sound cards were off-the-shelf, but Amiga's were not. Still, people upgraded their video toaster as far as 68060! I'm only a Mac-owning bystander here.

Nah, Texas is just part of that uninteresting stuff beyond the Charles River.

Holy tower Batman... when I was a kid, the tower I saw there was barely 4' high, like a Mini Golf tower.

It confused the heck out of me as a kid--Oklahoma looks like a pan, but Texas? It stretches the definition of "panhandle" if any rectangular protrusion is a handle. Here is an attempt to explain it. The original TI-Net BBS was called Panhandler BBS before we knew else that word meant.

I haven't counted the cycles, but here is my attempt at resolving the odd/even boundaries. I use MOV in slow RAM (thee of 6 wait states per word.) I only use MOVB in PAD. Here is one case where that counts: * wp in PAD so faster than movb in ram padws equ >83e0 r3lb equ padws+7 r4lb equ padws+9 src equ 0 dst equ 1 cnt equ 2 * src is odd, dst is even, cnt is even * src: a bc de fg h * dst: ab cd ef gh * combine dect/jeq, if cnt is always multiple of 4 copy: * cache first byte movb *src+,r3 loop: * fill two src words: * grab a word mov *src+,r4 movb r4,@r3lb mov r3,*dst+ dect cnt jeq done swpb r4 * grab a word mov *src+,r3 movb r3,@r4lb mov r4,*dst+ swpb r3 dect cnt jne loop done: rt This code is 16 words.

I saw this lot of 6 GPIB controller chips, TMS9914. https://www.ebay.com/itm/vintage-Texas-Instruments-collectible-microprocessors-lot-of-6-TMS9914ANL/202919510136 I'm not interested in using them, just maybe collecting one. The seller has other chip lots, and they are mostly peripherals, not CPUs. The other TI chip that caught my eye turned out to be a 74150, a 16-to-1 multiplexer. Its 8-bit little brother, the 74LS251, is found in P box cards, used to read out CRU bits one at a time.

I have a stock of 9901 from polida (eBay) but have not tested them yet.

I think it would have to be a game cartridge whose big fun has passed. So.. Hunt The Wumpus or Amazing or MunchMan have declined the most from their peak! I still use physical cartridges. Even FlashROM99 didn't make too much difference (it's handy for TI Workshop). I don't have a FG99. The ones I always carry around are still XB, E/A, DM2, Mini Memory.

The kryoflux can make raw flux dumps but I’ve never used those. I tell it to decode FM or MFM to image files. I dump both sides then join the chunks into a V9T9 DSK file. (TI track order is weird.) Using a script, I’ve copied about 400 disks.

I seem to recall there is some utility that reads the whole card in, then pastes your dsk images into that, then writes the whole thing out. That's not ti99dir then? BTW for those new to this, the CF7/NanoPEB only uses one of every two bytes, so 2GB is .. a whole GB.

I have not experimented with others. These are the kinds that came with/work with my CF7+ and NanoPeb (so far interchangeable) Sandisk 256MB Kingston 32MB Sandisk 2GB Ultra 15MB/s (this ridiculous size is hard to back up/edit with TI99dir!)

Yeah, that's a good beginning. I already verified the termination pack, and the (shunt) jumper is set to DS0. That's where I noticed the A-B-C motor jumper and changed it. I want to remove the logic board so I can see inside.

I am trying to test all my hardware, and I'm having no luck with floppy drives. I verified that my TI disk controller works with the original TI re-branded full-height drive. I bought a new-old Tandon TM65-2L DSDD, 360k, half height, perfect match. I intend to test it alone, so I put in a 150 ohm termination pack. The manual doesn't say what termination it needs but... It does not spin up. The light comes on. The spindle turns freely by hand at all times. On first power up, when it should spin, it doesn't. No busted caps (there are only a few electrolytic.) Not sure how to proceed with that one. Any pointers to resources? Basic maintenance? I found the TM-100 (full height) troubleshooting guide. I wonder if the drive belt is missing? I can see a shiny surface on the servo (nah, its labeled Step Motor) where I think there should be a belt. But it is not accessible like on the TM-100 full height. I moved JP7 from "spin up on MOTOR" to "spin up on DS" and I *think* I hear a slight whirring. I also have a TEAC FD-55BR from my own 80s CorComp MPES. It worked not too long ago, but now gets only read errors. (Its twin met the same fate earlier.) And I bought a used YD-888 but it does not spin up either. In the idle state, I can spin the wheel freely. When I attempt to read from floppy, the spindle does not turn. It freezes up. The light does not come on either. So there is a motor problem. Manuals: http://www.bitsavers.org/pdf/tandon/

I couldn't tell if that was current - so I used the built-in wizard. It has solved one problem! WinCUPL no longer borks when there are 2 files involved being edited in WinSIM. WinCUPL errors nicely and I can try again after I save changes in WinSIM. However this is an endless loop: So im done with this for now and proceeding with the LabVIEW version.

I don't think that will help. WinCUPL run an external programs which try to delete and re-write its output files. If it gets a mysterious error, it cannot get out of that state. Simultaneously, WinSIM expects to run the same stuff. It's full of synchronization bugs. I'm looking for some backward-compatibility option in Windows 7.

All of them! Bank 0 for starters. I hope that entire upper layers of the BIOS will be FORTH code. My device driver is written in FORTH.

WinCUPL was last supported on Windows XP in 2003. Documented bugs and crashes on Windows NT of the time. So, it crashes a lot on my Windows 7 machine. I think it behaved the same on Windows 10. The fact that Atmel (Microchip) still makes these chips and provides the old software... well... its something. It is two programs, WinCUPL to enter equations, and WinSIM to run the tests. Frequently, they open each other's files and the other one crashes. So I try to get as far as I can in WinSIM until I absolutely have to go back to WinCUPL to make code changes. There is a lot of mouse clicking on the graphics *output* boxes to enter *input* data like Clock, Input High, Test Output Low. Also, the chip I'm using is fully documented for the DIP package, but I need the PLCC package, and I gave up on making WinSIM recognize the PLCC pin numbers. Once I got all the tests to pass on the DIP package, I translated to the PLCC pin numbers and it passed too. Yay. Plus, the output window is blank after tests run-- it doesn't draw any graphics--you have to click or arrow around, to force it to redraw one column at a time. Probably a Windows XP compatibility thing. I don't know if there are some modes I can turn on in Windows 7. So, not a lot of fun, for a minor but necessary feature. I hear there is a CUPL compiler for Linux, I just haven't found enough info. LabVIEW NOW I'm in an even worse task: Test the actual, programmed chip, using LabVIEW 2013 to run my logic analyzer. Programming LabVIEW to read WinSIM files and run through the same tests. I've wanted to do this for a long time, and it will quite valuable going onward: it will work with the 99105 cpu or FPGA or video or audio card. But, to put it mildly, LabVIEW sucks. At least it doesn't crash. It took me all day Friday to make LabVIEW do the equivalent of this Perl code (which I can write in a minute here), just to read one of the WinSIM files: while(<>) { chomp; if ($_ =~ /PIN\s+(\d+)\s+=\s+(.+)/) { push(@pins, $1); push(@names, $2); } if ($_ =~ /\%END/) { break; } } But LabVIEW is what I've got. I can use to control the logic analyzer outputs and read vectors of inputs. I can use it to compile test plans onto a Xilinx FPGA, with all the inputs and outputs I could wish for running at full speed. It just sucks to program it to do what would take a few lines in C. AND I don't have all the C interfaces to work around it. And yeah, I was a professional LabVIEW programmer, and I hate starting from scratch.

Test equipment is one area where you want to quickly move away from homemade, to reliable standard. Debugging time is tedious enough without wondering if your tool is part of the problem. These are not for testing if the IC is good or not (you can't test an IC in place) but for taking signals off-board in a situation where an accidental short (by a probe) would likely crash the system. Test clip pins of the 0.1" pitch generation are flat at one end, 0.025" at the other, typically gold or silver plated. Once you move past chips with 0.1" pitch, the clip becomes much more complicated. For example https://www.digikey.com/product-detail/en/pomona-electronics/5254/501-2060-ND/745104 The plastic teeth go in between 0.05" spaced contacts. The farther down you go, the greater the need for a clip or a "bed of nails", as a manual probe just can't reach in. Here is some background on pins/contacts: https://blog.samtec.com/post/comparing-base-metals-connectors/

Sort of. XB switches to using 24K for the program storage, and puts only run-time variables etc in the VDP RAM. Do a SIZE command once you get XB. It shows you the two amounts free. The "missing 8K" is left unused, and is available for loading extensions, written in assembly language.

I'm interested in one. I haven't used this kind before.

I want to understand this too! I have used this code in a 32K cart version of "Bubble Plane", but with GenProg. Each level data is 16 row by 256 column (4K) RLE compressed (about 2K), in upper banks. Sound lists and char defs are up there too. Game code is all in bank 0. BANK0 EQU >6000 BANK1 EQU >6002 BANK2 EQU >6004 BANK3 EQU >6006 VDPBUF EQU >0010 * vdpwa address of uncompressed level data, swpb PADBUF EQU >8320 * 32 byte buffer that we use for moving data from vdp to vdp * trampoline code common to all banks LEVELS EQU $ DATA BANK1,CHARA1 DATA BANK1,LEVEL1 DATA BANK1,LEVEL2 DATA BANK2,LEVEL3 DATA BANK2,LEVEL4 * etc where LEVEL labels are each under DORG >6000, but intended for specific upper banks DATA BANK3,SNDLST * move some data from bank to vdp * R0 is vdp address * R1 is # index to LEVELS LOADLV EQU $ ANDI R0,>4000 SWPB R0 MOVB R0,*R15 * vdpwa SWPB R0 MOVB R0,*R15 * vdpwa SLA R1,2 AI R1,LEVELS MOV *R1,R3 MOV *R1,R1 SETO *R3+ * change bank, but this trampoline code is the same in all of them * R1 now maps into the bank MOV *R1+,R2 * length of level data * begin RLE decompressing level data into VDP RAM LOOP EQU $ * ... CI R1,>8000 JL LOOP SETO *R3+ * Cross bank boundary LI R1,>6000 JMP LOOP * when done: SETO @BANK0 RT So I guess for xdt99 my source would be LEVELS DATA BANK1,1#LEVEL1 DATA BANK1,1#LEVEL2 DATA BANK2,2#LEVEL3 DATA BANK2,2#LEVEL4 * source file with charset data AORG >6000+BANK 1 * source file with level data continues where charset data left off AORG >6000+BANK 1 LEVEL1 DATA ... LEVEL2 DATA ... * can I get this to wrap around to >6000 if it crosses a boundary? AORG >6000+BANK 2 * because I just know LEVEL3 starts in bank 2 LEVEL3 LEVEL4 * source file with sound data continues where level data left off AORG >6000+BANK 3 SNDLST Can I get xdt99 to have the data wrap around to >6000 in the next bank? I think GENPROG loaded relocatable 24K level data into 3 8K banks, each with base address >6000, and I had to hardcode what bank each level started in.

That's pretty neat. Much simpler and uses the CPU you already have! Lots of good links there--low-level floppy disk manuals from back in the day. Especially the Floppy Disk Users Guide, compiled for Linux reference in 2001. You can still learn more about your beloved floppy! Here's a gem: It has very clear explanations of interleave and skew (think Mike Dodd's Hypercopy and the fast MDOS boot floppies made using DSDD controllers by tuning this.) I finally know what hard- and soft-sectored mean. I have not seen one labeled as such since Apple ][ days in 1981.