FarmerPotato

Nobody writes eBay descriptions anymore. When there is one, it's chat-bilge. This one is so bad, it's funny. $35 Vintage 3M IBM Licensed Floppy Unlimited Device Usage Also: Unique! Don't Miss out! Ready to use! Condition: (less than good)

Hey! The BIOS I am designing for Geneve 2020 takes advantage of the supervisor/user modes of the 99105 to present a hardware abstraction layer to GPL or MDOS. Its job is to be a tiny supervisor OS, while making it possible to give 100% CPU to GPL or MDOS. As supervisor, it gets all interrupts or XOPs, then decides whether to forward them to GPL or MDOS. So there is some overhead on those for the goal of compatibility. By masking which bits each process may change in the LS612 memory mapper, it can assign any power of 2 memory pages to a process, which is protected from the others.

A souped up 4A with multitasking would still be a retro-computer -- it would be the kind that Texas Instruments would sell as a single-board 9900. Sure, it's a fish in a different pond, but it's not entirely without software. A 99/4A with fast 32K, or even 64K, could easily run TI's Realtime Executive (RX) and Microprocessor Pascal. This was meant for TM990/101 boards with maybe 32K. RX provided both interrupt-driven and cooperative multitasking, interprocess communication, memory heap management, and other services. The assembly language and Pascal interfaces are documented. We don't have all the source to RX, but the object code exists in the Microprocessor Pascal (MPP) floppies. RX internals are well-documented in the RX book and MPP. Other missing parts are Device-Independent IO and 2 other components. Anyway, I thought I'd throw that out there. Another inspiring OS is Xinu, which ran on a smaller PDP-11 in the 70s. The book is pretty good.

No breakthrough. In layout, I made a terrible mistake: a LA_3 via is next to a ground pad. I removed the solder blob, but it still shows as shorted. I had to bend back the ground pin of the LS259B: The vias under the LS259B are to get L_A1, L_A2 and L_A3 into the chip. It's very cramped at the edge of the board--lesson learned.

Yeah. DTE to DCE should be a straight-through cable. Going back to the 80s, why our RS232 card didn't have a CD input. The workaround was to wire modem CD pin 8 to RS232/2 input DTR. (I remember a classified ad in Micropendium, offering this open secret for $20.) Going back to the era, computer manuals show what was in demand: Terminals (DTE) with DB25 connected to a minicomputer port by about 50 feet of thick cable Terminals (DTE) connected to modem (DCE) transmitting to modem (DCE) connected to minicomputer Terminals (DTE) connected by current loop to minicomputer--1000 feet. Terminals (DECNet) - RS-423 differential, on 6P6S phone modular jack, straight through 6-conductor to minicomputer (it's beautiful) The minicomputer end - Texas Instruments had a 2x9-pin male connector. At VCFSW I was given a CI403, TI's 4-channel serial card for the 990. There are four, 2x9 pin, male connectors, with pin 1 used a key. It allowed a LOT of terminal ports to be crammed in. Interesting that TI did imagine 4 ports to be a normal amount for the Home Computer! The CPU card of the 990/10A has one regular DB25 for the console terminal. I have seen TI products with one or two TMS9902 to DB25 ports, while the CI403 has four 8250s. One TMS7000 board has a 6850 UART.

@TheBF In any 9902 code, it helps me to have the symbol names for CRU bits like XBRE, RTSON etc. Ive been very confused about RTS/CTS. A lot of 4A software leaves RTS asserted during a session. But I saw that T I source code only asserts RTSON before sending a character, then turns it back off. (The 9902 waits for CTS before actually transmitting, so I guess you don't have to.) Another puzzle is: why does the 4A's RS232 card implement a CTS output? I suspect the answer has to do with the 4A being wired like DCE instead of DTE. (Which is weird.) If it were acting as a DCE to another DTE, then it needs to acknowledge a RTS. That's not symmetric. The document that clarified what I should do was on T I's guide to interfacing UART chips and the "modern" PC DB9S connector.

@matthew180 When you posted last year about style, I fully converted my schematics (G2020) to a top-level block diagram, then fully routed wires on each hierarchical sheet. So, thanks!

On bank switch hardware: The Acadiel cart used one 8-bit latch. This goes way back. A write to cart space 6000 would latch in the low address bits. So writing to 6000 selects bank 0, writing to 6002 selects bank 1 etc... Remember the 9900 is read-modify-write, so if you have two latches they need to be at separate words. Unless your latch has read-back capability, writing to one byte will wreck the other byte. You could have a shared latch where 4 bits control a ROM space (say 6000 to 6FFF) 4 bits control RAM space (say 7000-7FFF). This is a pain to maintain... Unless you use CRU addressing. Doesn't work on late consoles--no CRU to cart connector. With CRU, you put in one LS259, it has 8 outputs, and you can address any bit field separately. It has a RESET pin to ensure bank 0 appears at reset. This is the choice I built-- 3 bits for RAM in upper bank (32K), 4 for ROM in lower bank. (64K) I think about two general schemes: One, the lower bank is ROM and the upper is RAM. Two, either can be ROM or RAM because there is a unified address space.

Gary, the part is LM1881. I built the same LM1881 circuit as @Shift838 did in the Genie box. The LM1881 is cheap.

Two bugs fixed, one new one. Via repair was successful. I'm not sure it was the problem though. Continuity measurement was unreliable! At U3 , the address latch, those outputs for L_A10,11 had poor solder joints. They sometimes conducted when I put pressure on the pin from on top, but not when probing the vias. Similar bug is L_A3 is shorted somewhere. I can deduce the addresses that data really came from. Worst case, L_A4 is shorted to L_A3 underneath the ROM sockets I just replaced. My construction skills are still short of what I'm trying to build. It could be the amount of solder paste. I imagine little solder paste stencils for 1-chip footprints. With local registration holes.

So I took out the sockets. Put in the last two I have. New chips. Very easy to insert. But still no good. I also replaced the bridge to the logic analyzer. The DuPont crimps are wearing out and I guess that's why I get so many tiny glitches. Problem is continuity between the address latch and ROM. Address lines L_A10, 11 are bad. They read solid 0 or 1 at the origin, but wobbly at the ROM. I traced L_A12 as a control. So likely the ROM was not the problem all along. The floating input could result in the address pointing into all FF. The L_A10 and 11 traces have continuity between the two ROMs. I've deduced that the break is a damaged via. Under the brand new plastic socket. I'm stuffing the via with tinned bodge wire.

I'm using the puller that came in the XGecu kit. Goes under the corners. I have damaged chips taking them out.

@Ksarul Um what do you mean by dead bug, flap, live bug in PLCC? In the prior board, I used ZIF DIP sockets (lever) happily. Might go back. At one point I drew two Memory Mezzanine daughter boards, one using DIP. Amphenol says the PLCC socket life is 25 insertions. My problems are at the short end of PLCC-32 (sides are 7,9,7,9 pins). But then, on microscope I can't see any gap. I tried two new chips, same problem. But on one try, I got out 00 instead of Ff when I poked two tiny wires into both RD and CE. Expected 80. (So maybe still got AD15 shorted.) Chips are SST 39SF010 (128K x 8 ) PLCC. Guess I'm going to have to swap in new sockets. Again.

Yes, that's right. I've was thinking about an interpreter for direct threading. Instead of a pointer in the CFA (for instance to DOCOLON or DOCODE) the code is inlined and it is reached by BL *W. One less indirection, but lots more memory used. Hopefully faster? Anyhow taking that to Forth thread. I too believe the stack should grow downward. Maybe the return stack is fine to grow upward?

The 99000 has a BIND branch indirect instruction for that. BIND *R10+ fetches the word at *R10, increments R10, then puts that word in the PC. How it returns is up to you. BIND takes any addressing mode. B R8 is sometimes useful. You could set up an instruction in R8,R9, with another B in R10,R11 Or load R8 with the opcode for "B *R11" then do BL R8. This is a way to get the PC in code that can be moved around in memory.( If only there were a STPC instruction.) 99000 defines another, BLSK, Branch and Link Stack. It is like BL branch and link, except the return address goes onto a stack instead of R11. Unfortunately, BLSK only takes a stack pointer register and an immediate address. So can't do BLSK *R5. Just BLSK @SUBRT,R10 It decrements R10 and pushes the return address *R10. You can however: MAIN BLSK @SUBRT,R10 ... SUBRT BLSK @SUBRT2,R10 BIND *R10+ return SUBRT2 BIND *R10+

I do have those. The surface mount kind, I found, are easier to route. it's not the PCB to socket, it's the socket to chip that's no longer making contact.

Seriously considering DIP again for the EEPROM. When I replace the LS612 memory mapper (DIP-40) there will be room. And it will simplify the address/data bus route. -- The PLCC-32 sockets were Amphenol brand, fresh from Mouser. At least 10 insertion cycles so far. Anyone have advice here? How to keep PLCC sockets in working order? (and why would both fail in the same remove/insert cycle?)

Oops. I understood VFILL to mean VDP fill and that it went horizontal. Like I'd think of 0 768 32 VFILL to clear the screen. I also found it annoying that vaddr is below len and char. If I'm iterating on vaddr, it requires a nasty 2DUP I -ROT to prepare the stack for FILL/VFILL. I imagine a ! order: : VFILL! ( char len vaddr -- ) SETVWA 0 DO DUP VDPWD ! LOOP ;

Update: I was stuck finding shorts. First AD15 was shorted somewhere. Probably at the RAM. But so was VCC-GND. I found it last night after desoldering the accused culprit RAM chip again. The short was a solder whisker, on the farthest, unused RAM footprint. The pinout of this RAM is smart but tricky. To reduce switching noise, they put VCC and GND on the middle pins of each side. Which makes them easy to short. I lost a lot of time on the assumption that my RAM had some solder bridge underneath. I'm getting weary of build difficulties. With that short found, I find that my ROMs aren't working. It seems like the two PLCC sockets' springiness has worn out, at least on the side that has chip select and output enable. Weird that its both. The signal reads perfectly AT the socket, it just doesn't reach the chip pin. (I poked a wire in because the probe tip is too wide.) Either I managed to wear out both PLCC sockets at once, or the chips have some weird damage. But I was able to read, rewrite and verify them on the T56 last night.

Sorry, I'm not setting any ship dates. It's been my passion for the past four years...

I too hit this wall, in my BASIC days. My answer was not to reverse the velocity, but to force its sign to point away from that wall. Prior to that , I had a lot of balls sticking to the wall, or climbing it stair-step fashion. V=1 IF X>30 THEN DX=-V IF X<3 THEN DX=V Another way is to test both conditions: IF X>30 AND DX>0 THEN DX=-DX Yet another approach was to rotate the velocity vector by 90' IF X>30 AND DX>0 THEN A=DX::DX=-Y::DY=A This only works going clockwise, something that stumped me until I got enough algebra-not to mention the physics is weird.

OK, to be more device-independent, without implementing the whole CURSES package, you can DEFER a set of output words like GOTOXY, HCHAR, VCHAR. (I would replace the BASIC-style HCHAR too.) Make a cursor position variable and set it: 12 5 GOTOXY. If the device is a terminal, GOTOXY sends the escape sequence, otherwise it computes a VDP address. Other decisions to man include: how to store current position, whether to optimize GOTOXY as a delta to the current position... A little farther down this road and you need a "graphics context" to cache settings.

I kept thinking about this... If reaching down more than 3 levels into the stack is bad form, then maybe the BOX interface BOX ( x1 y1 x2 y2 chr -- ) is not Forthlike. Influenced too much by BASIC or another language. I came up with a 3 word interface: CHAR ( chr -- chr ) ORIGIN ( x y -- vaddr ) BOX ( chr vaddr width height -- ) Example: 42 CHAR 12 5 ORIGIN 10 10 BOX Char is a do-nothing word for now, but part of the interface. 32 VALUE COLUMNS 0 CONSTANT SIT : CHAR ; : ORIGIN COLUMNS * + SIT + ; : BOX ( chr vaddr width height -- ) COLUMNS * ROT ( chr width h' vaddr ) TUCK + SWAP ( or SWAP OVER + SWAP ) DO ( loop on vaddr ) ( chr width ) 2DUP I -ROT VFILL COLUMNS +LOOP ; optimization: a word COLUMNS* that uses a shortcut to multiply by 32, 40, 80 depending on graphics mode.

I haven't come across something like that. It's a case statement. Much simpler, but in TI books, I have seen a lot of: BL @MOVPAC DATA ERROR if the routine is successful it does INCT R11 but if not MOV *R11+,R11 RT

Pretty fair price for Pcode and everything but the P-box. $300 for Pcode, 32K, Texas Instruments disk controller, RS232.. throw in a console and original 10" monitor. Seller's other lots include many nice original floppies from ASD&D, Not Polyoptics, Asgard, MG. Another set is 20+ original 99er on disk.