FarmerPotato

It's possible, I have done it, and in 1986 I wrote a utility "Supersave" that automated the process of making an EA5 from multiple EA3 files. It worked by checking the next free address pointers in high RAM before and after loading. It would not handle programs that load into low RAM, code that is not simply relocatable object code, or programs that depend on having the E/A utilities in low RAM. If I were writing it today, I would make a complete new loader that handled all these issues correctly. Finding my original program Supersave has been tough.. I have a bunch of ARC files that I can't seem to open.

Thinking about doing sprite bits COINC in assembly. This is a good fit for the CZC, COC, or SOCB instructions. It might be too cycle intensive to test all sprites, so pick the ones to test. It can also be effective at testing sprites against background chars. Bitwise Sprite COINC This code demonstrates testing for overlap between two 8x8 sprite patterns in CPU RAM. Assume you did coord testing and their 8x8 boundaries overlap. Sprite #2 is asssumed to be down and to the right of sprite #1. Other situations are left for later. 16x16 sprites are left for later. If you have multicolor (2 sprites together) it is probably best to create 1 combined dummy char pattern to test against. It will be an advantage to operate on everything in CPU RAM (keep SATB in CPU RAM, write the whole SATB to VDP on each "tick".) Here is a picture of an 8x8 ball hitting an 8x8 ship: R1-> 1111 R0 ^ 111111 <--> | 11111111 | R3 11111111 v R2->1111111*2 * = collision 1111111*2 11111122 1111 22 22 222222 22222222 22222222 PAT DATA >3C7E,>FFFF,>FFFF,>7E3C DATA >1818,>1818,>187E,>FFFF ... LI R0,4 x separation. needed in R0 for SLA LI R1,PAT sprite#1 pattern address LI R2,PAT+8 sprite#2 pattern address LI R3,4 y separation BL @HT JNE GOTHIT ... ... HT A R3,R1 LI R4,8 #rows to test S R3,R4 CLR R5 test/shift register CLR R6 test register HL MOVB *R1+,R5 SLA R5,0 shift #1 pat left by R0 places MOVB *R2+,R6 CZC R6,R5 if the 1s in #2 are all 0s in #1 JNE HX DEC R4 JNE HL HX RT return status: EQ if no hit, NE if hit.

One way: JediMatt USB adaptor allows you to "drop in" a USB keyboard. I'm looking at portable USB keyboards that fit into the vacated rectangle. On the other hand, a from-scratch keyboard PCB wouldn't need the USB adaptor. Any key layout could be translated to the 4A's matrix, using an Arduino Nano (maybe even an ATTiny) plus some lv165a, hct595.

Cassette tape coating line opens, first since 1983: https://www.news-leader.com/story/news/local/ozarks/2018/01/07/world-running-out-cassette-tape-now-its-being-made-springfield/852739001/

I was about to tell arcadeshopper "hold my beer" while I dremeled out a 4A case to fit a scrapped Dell laptop keyboard, but, you made the point right there. Not as much fun as making a PCB though. I use laptop style keyboards exclusively around here (IceKey and MacBookPro mostly)

There's a project there for someone to work on. There was a PCB made and keyswitch buy at our hackerspace, so I've seen it done, and if you google "make your own keyboard" there are lots of hits, but they cost a pretty penny (up to $250.) I see questions: 1. where a few more keys could be fit in? One more column would help accommodate the modern keycaps like Slash-QuestionMark, Quote-DoubleQuote, and Minus-Underscore. Arrow keys sure would be nice. Splurging on real estate for a whole row of FCTN keys, well, crazy talk. 2. Modern keycaps wouldn't have the front key symbols like ? painted on. 3. Should the electrical interface emulate the signals at the original TI connector? or should the ROM be changed to a new KSCAN? Perhaps, even both could be accommodated somewhat. (programs that poll CRU only to check for FCTN-4 for instance.) . What if the keyboard has the Slash-QuestionMark. Pressing ? would imply the signals for FCTN and I.

My retail places are long gone. In Lubbock, Texas, I was able to play with all the home computers and video games at BEST Products which was a catalog showroom. They had one of those big Atari 2600 walls with 100 game selection, a TI-99/4A demo wall with cartridges on retractable wires, also VIC-20, C-64, Intellivision, ColecoVision, Atari 400/800. You could ask a salesperson to open a cartridge box behind the counter. If you bought something, a box would be brought from the back to the checkout. There is still a Sears store standing where I played Sears-branded Atari, the Intellivision, and Odyssey game systems (KC's Krazy Chase). Come to think of it, this was next to the Radio Shack where I saw the TRS-80 and CoCos. I'm lucky to live near a Fry's Electronics .. for all their clumsiness, they still do more than Radio Shack did.

This week on Orville's S2E2 the Captain referred to android Isaac as "A Glorified Speak and Spell."

I grant you have a better grasp of instruction cycle counts. Also, I might be reluctant to tackle the cpu. Your idea of eliminating wait states on read-before-write. I think this is solvable (in a new mux, CPLD) by caching the instruction during IAQ. For starters, just recognize MOVB (Dxxx). The mux could then skip the second DBIN cycle when it is in 8 bit space, then write one byte on the WE cycle. Imagine a new replacement board for the mux that adds fast 16-bit devices (RAM, 16-bit cartridge ROM), and forwards 8-bit memory accesses as usual (skipping bogus wait states on read-before-write.) Alas, I'm back to work on using the side port as-is.

There is no sound out from the 34 pin cartridge port, though nothing prevents a cartridge from packing an extra memory-mapped device like a sound chip. The side port has an AUDIO IN though. Speech and MBX are the only peripherals to use it AFAIK. There was Marc Hull's Sid Master, a card for the Pbox. (last produced 2005 ish?) There have been MIDI cards. FORTI was a 1982 project by a TI engineer (Lee Cantwell?) which put 4 TI sound chips on one card. I am working on FORTI-2 which will be a sidecar peripheral and offer unlimited stereo audio possibilities. Like the original FORTI, its native language will be FORTH, but it will be accessible from any language, including access to 12 voices from BASIC. You will be able to load waveforms from BASIC with the delightfully wacky format CALL SNDCHAR8(1, "01FF") (set voice 1 to a simple 8 bit sawtooth wave, interpolated.) To put it back to a basic square wave, CALL SNDCHAR8(1, "01FF", I am testing with the free AKWF set downsampled to reasonable memory size for the 4A (they sound.. not as good). As a bonus, AKWF has samples for a lot of 80s sound chips! FORTI-2 also has its own SD card slot, so loading the samples by name should be a much better way to do it. Imagine CALL WAVE(1, "AKWF_0167.WAV") The changes persist (FORTI-2 requires external power) so you can change the timbres and then play Parsec, for instance. (I'm using a sound list from Parsec in my testing.) I have over 200 hours into this project in 2018. Mostly spent debugging (current bug has FORTI-2 occasionally disrupting a memory cycle, typically crashing the 4A.)

The TMS9900 is efficient with bus cycles -- it's the speed of 8 bit cartridge ROM and GROM that need to be improved. We've been actively discussing it on the Development board. For example, reading an instruction word from the XB ROM (or any 8 bit memory) consumes at least 6 clock cycles, which could be shortened to 1 with 16 bit wide chips on the 16 bit bus. Setting a GROM address (in preparation to read) takes 30 clock cycles (I was horrified when I measured 10 microseconds of... waiting...) (1 clock cycle = 1/3 microseconds) This too could be reduced to 1. I'm working right now with a cheap 10ns 512k SRAM for everything. The memory modifications have been accomplished in various ways by different people, but not widely available like a board you could drop into the 4A. Having fixed memory to get the full potential of the TMS9900, one could then think about replacing the CPU.

I'm not diverting any hours to it, but my head is full of Sequels and Mashups of TI games. The most famous of these, in an alternate 90s reality, is "Cars and Carcasses and Katamari" in which King Knut Polyoptics tasks you, Munch Man, with pushing a giant ball through a maze, squishing vampires, zombies, and Hoonos, while avoiding gravestones. As you squish more carcasses, the gory ball grows, and your view of the world expands, until you realize you have always been inside a game of Zero Zap.

Thank you! I have read that now. It does document every detail.

Right, I'm inferring the data bus from what I see on the mux. Which so far matches the low byte of all the ROM and PAD reads I have checked, but I need to check the logic for the mux to see what it does in all states. I do suspect that some of the >10 values are the cpu holding its data bus in hi-Z just after a read cycle completes. At some point I'm going inside the side port to bypass the mux and bring out the 16-bit databus.

Has anybody documented the undefined behavior of the TMS9900 data and address buses when no memory cycle is happening? I noticed this today while debugging a hardware glitch (unsuccessful so far): During the Add instruction, the databus repeats the two operand values. I don't see this behavior documented in the TMS9900 manual. It seems like a nice feature to have. I guess it's the ALU "leaking" its values onto the data bus. What does an Add instruction do? The sequence of operations is roughly: instruction fetch instruction decode fetch source operand fetch destination operand internal ALU cycle (in this case, ADD) store destination operand Here is an observed sample case where the cpu adds 0010 + dec8 = ded8: My registers: WP 83E0 PC 7d32 (whole program from 7d00 to 7d80) R0 0010 R5 A000 Bus observations (each row is at least 1 clock cycle): ADDR DATA Signals Action 7d32 a540 MEMEN DBIN IAQ read instruction: A R0,*R5 ???? xx40 decode ???? xx10 decode 83e0 xx10 MEMEN DBIN fetch R0 from 83e0 a000 dec8 MEMEN DBIN fetch dec8 from a000 ???? xxc8 internal ???? xx10 internal a000 ded8 MEMEM WE store result to a000 xx are the high byte I can't see (I'm reading the side port. I only see one half of an internal 16 bit bus read.) ?? are addresses I missed cuz I only grab the address when MEMEN is asserted. The internal cycle values xxc8 and xx10 match the destination and source values. I'll be taking more notes on other instructions.

For more than 15 years, we have operated Midwest Gaming Classic on the model of "get everything out of storage for one big event where everything is hands-on." Nominally, our storage bins say "Electronic Gaming Museum" but any plans to make that a permanent physical building were long ago abandoned. Instead, we get up to 17,000 people in one festival (the weather took its toll last year) and the wonderful families where multiple generations get to share playing games their folks remember. "Hey! You have my dad's favorite game on disk! Can I take it to him so he will come over?" People trying to draw with Super Sketch. One time repeat visitor: "Can you give me another TI BASIC lesson?" Hardcore gamers attempting TI Invaders. Academic wondering at the TMS9918 minor dazzlements: "They thought of layering sprite planes and graphics back then?". Twice, original designers of TMS9980 and 32C020 microprocessors. Habitually, TE2 speech jokers making the computer say juvenile things. Scott Adams opining on TI's business decisions (he had ignored all things 4A until our show) New combinations.. CF7+ on a 99/4, all the newest gadgets on 4A Impromptu Munch Man world championship (somebody walked up, got to level 20, attracted crowds) These are some reasons why I do this.

I have so many abandoned projects from up til 1991, that have never been shown outside one or two UG meetings. The complete catalog of Gadego Software: Blue Bert - a Q-bert type game with animated cut scenes. Basic, then XB, then XB again, then all Assembly. Neandro - a Bag Man type game with cavemen and dinos designed by Matt Storm, all assembly. Cytron Masters clone (Apple II game) bitmap tiles, real time strategy game. Bubble Plane - actually this one shipped as an A/L game loaded from XB, and as an all A/L 32k cartridge image for Geneve GPL env only. Reviewed in MicroPendium. AdventureQuest - CRPG in many versions from Basic to XB with A/L support, then all assembly, then Geneve. Roughly Ultima 2 type technology. Hobbit - replacement for TI-Net BBS, in all assembly with the initial design in C and coded in A/L one subroutine at a time. Never got further than User Login / create a lot of databases. TE-Free - dumb terminal program demonstrating the Hobbit A/L support library. Green Watermelon Fractal Hacker - 4A then Geneve Mandelbrot explorer, also animates the set of Cantor sets between any two points. Finished, never published. Vantage - drawing package for 4A bitmap, according to perspective drafting principles, intended to draw wireframe scenes for 3D dungeons, but from any POV. What I did in Algebra II instead of listening to the lecture. Completed on a Mac some years later. Countless XB games I abandoned.. I still have all the graphics on paper with colored pencil. The first three games suffered eventually from the same terrible bug, which I suspect now was the heat death of the TMS9901 in my CC9900. I have a user ISR hook, but interrupts seem to fire more often than 1/60 sec, and interrupts monopolize all the CPU time and everything goes super slow. But then I saw the same behavior on TI sidecars. It was beyond my ability to debug. I dug up AdventureQuest for Chi Friday, but it will remain under wraps until after Adamantyr ships his game, which is far superior. (The one really cool feature I had was a 2x2 tile, 32x32 pixel dragon that existed on the main world map or a dungeon, where you and everything else are one 16x16 tile). For now my only project is FORTI-2, which consumed at least 200 hours in 2018. There.. my brain dump of unfinished software goals from my adolescence... now back to the working world

Hi y'all, I really enjoyed visiting your monthly meeting last May. It was all too brief and I wish I could visit again. I considered the possibility of another trip to Portland, but, one family member is going there in March, and then I'll be doing the usual 3 or 4 tables of TI gear at Midwest Gaming Classic April 12-14. https://www.midwestgamingclassic.com/ That should have zero impact on your event... its me and about 4 99ers from the Midwest. If you choose that date, we could set up Chatti!

Or if all of the GROM in the console and XB cartridge were moved into a zero wait state GRAM device. GROM address setup takes nearly 10 microseconds during which the GROM asserts the HOLD signal (READY low). I was still surprised when I measured this on my scope recently, though Tursi had done a comprehensive bus timing document earlier this year (I skipped the sections on GROM.)

Here's my list. I may or may not have drawn chars for these back in the day (: Space Duel Elevator Action Star Castle Crystal Castles TRON Rastan Gauntlet

I found the bug Saturday, but I don't understand it. If I remove the FF initializer or change it to 00, the code works: Verilog output reg [7:0] addr; always(@negedge i_serclk or @negedge shld) if (!shld) addr[7:0] = 8'hff; else addr[7:0] = {addr[6:0], i_q}; There is SOMETHING wrong there that I just don't know enough about. Is it that initializing to ff requires an SR flip flop and something is off in the clock domain? But using 00 requires only a D flip flop and the code works? I dunno. There is more code to generate a shld plus 8 serclk cycles. This code passes my unit test pattern: i shld serclk addr 0 1 1 xx 1 0 1 ff 2 1 1 ff 3 1 0 fe 4 1 1 fe ... 17 1 0 55 18 1 1 55 PASS Code links: https://github.com/olsone/icetea/blob/master/shift_ser_in.v https://github.com/olsone/icetea/blob/master/shift_ctrl.v In hardware, the shift register leaves some 1s in the high bits. Its like it gets re-initialized or only shifts in 6 bits. If I change the initializer from 8'ff to 8'f0 or remove it, a2 is 0. a2 is stuck when I use 02. If I remove the '!shld' branch, everything works in hardware too. There are two of these 8-bit shift registers, but the order of address bits in is scrambled to simplify PCB trace layout. So the top four bits there are actually a9, a2, a6, a1. PAGE in the scope traces outputs the resulting A0, A1, A2, A3 nybble. Only a2 is stuck high. And a1 has always shown correct for all 8 permutations of A0,A1,A2 address in. I'm going to send the full 16 bits address results out on SPI for further inspection.

Interesting idea about the audio probe. I used to get plenty of audio input through the RF modulator. I can still hear in my imagination the sound of KSCAN running over and over, and the sound of an endless RESEQUENCE. In this case, the scope already tells me much, and the software problem is inside a 100MHz FPGA domain.

whoa, you are in for a treat. Electronics Goldmine doesn't always have what you need in stock, but, they often get things you must have.

I see you're rounding down, in favor of going faster. Correct? I looked at source code and found that TE3 had >1A1 for 1200 baud - rounding 1E6/1200/2 = 416.7 = 1A1 = 1199.04 bps. At some point I corrected this to 1A0 for TI-Net BBS which is 1201.92 bps.

Thanks for confirming that. Background: U3 and U4 are TI SN74LV165A shift registers which latch the TMS9900 16-bit address from 5V LS TTL, and translate it to 3.3V CMOS over SPI. The SPI transmission completes before the first wait state. For a board with 48 GPIOs, I attempt to squeeze the whole 4A sideport interface into less than 24 pins, leaving 24 free GPIO pins. I have ruled out hardware as the cause of A2 being stuck high. I cut the A15 trace to the address latch. Same behavior as before. I considered for a while if there was an effect from that slot between the two green ground polygons. Because there is a lot of noise in A15 when measured at the console edge (red analog scope trace in the pictures above). Nope, ground planes are connected together adequately. Noise went away when I cut A15 though. Went to the hackerspace. Nobody else was around, so I spent a lot of time using the stereo microscope to inspect my board. All my effort has at least eliminated noise on many signals like the SPI bus. A big culprit turned out to be an extra 6 inches of ribbon cable on my logic probe, when I switched to a teeny short cable. I can watch the SPI bus and see there is no problem with any address bits being latched correctly. The evidence is now that this is a software problem. Time sunk into this is now like 100 hours, clearly a case of premature optimization, changing 16 parallel address bits to 4 bits of SPI + A15, net savings 11 GPIO pins. I might as well retitle the whole project "Attempt to transmit the 9900 address bus as a SPI frame plus A15."