FarmerPotato

Video Broadcast for 99/4ATX on weekend of Aug 8-10! We will have a Ustream channel. When no one wants to broadcast on it, it will point at something interesting, like a computer demo, a 3D printer, or a breakfast taco. You never know! https://www.ustream.tv/channel/u45p8uc7YSS I picked Ustream because the free trial seems better than freeconferencecall.com or Zoom.

Making the RAM fast and large is a perfectly fine goal, it's just not possible on the cartridge port. 9900 doesn't need cache because its clock is only 3 MHz and cheap SRAM even from the late 80s needs no wait states. Cache is a necessity when your CPU is clocked way faster than the RAM; today your x86 is clocked in gigahertz and your RAM at 800 Mhz. TheBF had some good ideas about replacing the side port with a 16 bit fast memory bus to the PBox (I hope with a backwards compatible adaptor as an option). Others have put fast 32K memory inside the console. We don't need a cache, we just need RAM in the console that is 16 bit and no wait states. Modern SRAM is fast and cheap. For instance, this 512Kx8 thru-hole SRAM is $5 and is the type used in SAMS cards (and hopefully future Horizon RAMdisk). And this 512Kx8 or 256Kx16 part is $3 and $5, operates up to 100Mhz, and comes in a surface mount package that is just a little harder to solder than plain old 0.1" thru hole chips (SOJ-36 with 0.05" pins, you need a magnifier, and a knife edge K solder tip.) It would be hellacomplicated but you could make an in-console 16-bit bus tiny SAMS upgrade around that. Then again, I have more ideas than time or attention span.

I'm still waiting for the actual cart boards from DirtyPCBs (where they cost $2.25 each). I held it up until I added the peg hole into the board (oops). EDIT: they were made on 7/15/19, shipped out of Hong Kong on 7/18/19. Hope they get here by Aug 8. BUT I will have this test rig for the ATF22V10 logic chip (PLD) from OshPark next week. I couldn't work with the PLCC to DIP adaptor that came with the TL866 / XGecu programmer. (It doesn't fit a breadboard, for one.) It it a PLCC-28 adaptor with two sets of pins: one set on the bottom plugs into a breadboard, while the top set is for a logic analyzer. All the pins on top are labeled. This will let me test just the bank register, and re-write logic, on the PLD.

I think that considering a 512K flash cart as a big RAM is off the track. You could replace the chip with a large SRAM (for about $20) and have a mega-Supercart, but here are the numbers, like mizapf said: Relative Speeds (not including instruction overhead which is pretty big.) 1 PAD 16-bit access in 1 cycle each for read and write. 6 32K expansion 8-bit access in 6 cycles for read and write of 1 or 2 bytes. 2 x (1 cycle + 2 wait states). 6 times slower than PAD. 300 Flash - same read access as 32K, but takes 9 writes to program one byte. Plus a lot more instruction fetch and executes. So it will be at least 20 times slower than the 32K RAM per byte, or 40x slower per word. I'm guessing 50x after overhead. In other words, writing to Flash is best suited for saving small amounts of data or loading a new cart into the thing. I spent a lot of hours with the logic analyzer on the side port watching Mini Memory and 32k accesses. I know it pretty well by now. Tursi also made a great document from his logic analyzer of all types of memory cycles. I'll record the bus activity of the flash-writing code listed above to know for sure what the relative speed will be. (I have simulated my tests so far in the WinCUPL simulator from the Windows 95 era and I really, really have grown to hate it.)

OK. We have a really nice Hakko desoldering vacuum gun and ChipQuik. Makes it a breeze. Bring a 40 pin socket.

We can get one out of a scrap 4A for you. Otherwise it's about $3-$5 from China, $30 domestic. I forget whether it's soldered or socketed, but no problem, we can desolder at the Hackerspace.

I think you described that you disconnected the keyboard, and touched pins together to mimic keys pressed? In that case most likely the 9901 chip is bad.

You just made my day. I missed this whole thread before!

Oh crud, my brain just worked out a possible harebrained scheme to keep the >6000 space locked to the first 4K (bank 0) while allowing the >7000 space to map any bank (7 bits). That means many hours more of simulation and testing... NOOOOO! It's not possible to give the bottom 4K the ability to switch in some different banks. This would be a choice at the time the ATF22V10 logic is programmed: regular 8K banking, or fixed 4K + banked 4K. Such a scheme would allow the programmer to have all the library code in bank 0, plus the main program loop, calling lots of subroutines in the other banks. The file system code would execute from bank 0 and use the upper 4K to map in the storage space. Just to re-clarify, this cartridge is not a general-purpose storage device. The program inside it would have to be written specifically to use it.

Answering your questions in order: I think a regular DSR is too complicated to adapt. Cartridge ROM is not searched by the usual DSRLNK? Accessing it in the cartridge space is tricky. I have read the source though and I think the Horizon DSR is excellent. I would like to use it on a sidecar. The 512K Flash chips are as big as it can go. The next size up, 1024K, is not compatible with 5V (3.3V only), costs $5, and doesn't come in an easy to solder package. See Tursi's Dragon's Lair cartridge for an example of surface mount Flash, 1024K I think. Novice soldering skills must be enough, so no surface mount, only thru-hole. My cart is not intended to be like FinalGROM, for one thing it's not capable of doing GROM. FinalGROM uses a proper FPGA to do all the emulation. UberGROM uses an ATmega128 microprocessor to emulate GROM, which is a pretty good low-cost solution. My cart just has a cheap logic chip with 10 bits of memory. My goal is to make the lowest cost multi cart out there (now $8) but still distinguish it from the old 512K multicart by adding save capability. This design is locked down now (lots and lots of hours put into it...) Upgrading the logic to have 20 or 32 bits is beyond reach. The cheap XGecu programmer doesn't support these chips: ATF750 or ATF1502. Newer logic chips are not easy to solder. Aside: I'm operating outside the usual path by skipping Xilinx FPGAs that everybody else has used. I'm a sucker with an emotional attachment for the underdogs. (Sound familiar?)

Also, if your registers are in PAD (e.g. >8300) then arguments in registers save a lot of cycles. Fetching the address from 8-bit memory costs 6 cycles after wait states, but fetching a register is 1 memory access. * Really fast code assuming registers in PAD LI R9,GADR STWP R0 INCT R0 * set pointer to R1.. could be LI R0,MYWS+2 or LI R0,>8302 MOV *R9+,*R0+ * copies to R1 MOV *R9+,*R0+ * copies to R2 MOV *R9+,*R0+ * copies to R3

I did some initial design of a FAT-ish file system using 256 bytes at a time. Since the flash is rewritable by changing 1s to 0s one byte at a time, but not the reverse, it would work like this: A program (that had been copied to the 32K) would embed a library of routines to manipulate files (no DSR). It could look up a file in the directory, find a list of sectors (16 bit numbers) and read 256 bytes at a time. Then it could append to the file. Rewriting part of a file would mean that sectors are replaced in the list by new ones, but only if the whole sector list is buffered in memory. Closing the file would mean writing out a clean copy of the entire file, then marking the old file as deleted. There is an allocation table with a bit to mark each sector as used, and another table where sectors are marked deleted. To keep things tidy, new files would start on 4K boundaries. So whole deleted files could be erased, and the allocation table could be erased and rewritten. This is ideally suited to: large read-only files appending to files non-indexed databases (linear search, skipping deleted records) especially a database of high scores writing a saved game, or rewriting it It's remotely possible that this could be done on a system with no 32K. Especially a simple task like saving high scores. VDP RAM would be required to buffer some tables and sectors while tiny routines executed out of PAD (bank switching means the ROM disappears while file sectors are mapped in.) Aha, I have already checked to see if the write byte routine fits into PAD! HOWEVER, I am not going to work on this file system, only working up until the testing of the 512K bank switching and writing is done. The file system is just a spec. Too many projects!

To clarify, the bank switching is the usual 8K. It is the SST flash chip that supports 4K eraseable sectors. They would still be mapped in the cartridge space as 8K banks. I can't get to 4K banking with the $1.42 PLD I used. It only has 10 bits of storage. Sorry. Hey, I just did some research and I think replacing the ATF22V10 with the $2 ATF1502 will make 4K paging doable. It has 32 bits of storage. Some Atari folks have used the $3 ATF750 but that's near obsolete. Going full Xilink like the FinalGROM or NanoPEB is a $9 part. My first goal has been to minimize cost. By the way, I'm getting 2 thru-hole sockets from Unicorn Electronics which adds $1.09 to the build. PLCC-28 and PLCC-32.

TLDR; still points to what others have concluded, one bad VRAM chip, bit number 6. This is fascinating.. only three spaces >20 are transformed into quotes >22, each time in column >09. (but not column >19) Characters A and 1 have a bit set at VDP address >989 and >A09. Other letters in this sequence would be ! and Q, which we don't get to see. Inside the TI logo chars, >809 is normally set. >849 is also inside the TI logo and NOT set normally or in the picture. >889 and >8c9 are not used. Then Color bars.. they are all clear and background color, foreground transparent. Characters >60 to >D8 are the color bars. They must have the >02 bit set consistently in VDP memory in at least >B00 - >B07, from >B40 to >B47 and so on upwards through >E47. (pattern descriptor table. .) VDP RAM above that first 4K is unused by the title screen.

PM me your address and I'll save one for you. I stress that this is about to start the testing stage. The boards are at DirtyPCBs, where the protopack is $20 for about 11 boards (10 cm size. Cartridge is 98 mm by 59 mm I recall.) I designed and ordered a test jig from OshPark to help verify the logic behavior.

I like both the Parsec and Wumpus shirts. I can see wearing them to work.

Are you talking about piggybacking onto an existing cartridge, or making your own from scratch? If you're piggybacking on an E/A cartridge, which has no ROM, then it's fine. In general, writing to the cartridge port is how bank switching is implemented. Cartridges that this will affect include Extended Basic, and recent multi-bank carts. It's not the data bus that switches the bank, it's the low-order address bits. I am not entirely sure, but I have no idea how most cartridges distinguish between read and write cycles. I think they don't care and just clobber the data bus by interpreting a write as a read. If you are making your own, and you have an EPROM on board, you need to ensure that the EPROM does not treat the write cycle as a read and clobber your data. You'll need to add a NOT or cheaper NAND gate (74HCT00) between the DBIN signal and the OE* pin of the EPROM or other read-only memory because the logic values are opposite. I think this pin is usually just hooked up to ROMS*. Cartridges with RAM like Supercart do use the right signals. Start here at TI Tech Pages.

According to datamath.org it uses the TMS5220, also in the Speech Synthesizer. (That is a great web site by the way.) (Other chips: ROM is CD2228, microcontroller is C14007) Mame source so far There did exist an interface from the 4A to the Magic Wand's RJ11 jack, replacing the wand. The one that I saw was a few wires to the joystick and cassette ports. This was used to test drive the Magic Wand by sending bar code data. Going the other direction might be just as feasible. The bar codes in the books begin with pitch/slope info (or code for loops) followed by allophone numbers. So the sounds you get on the Speaking Reader are much like what you can create with TE2 text-to-speech. Some of them have codes to do loops or multiple choice quizzes (it waits for you to scan the answer.) There will be a display of TI speech toys at Fest 99/4ATX . Al Olson was a TI engineer who worked on some of them (esp Magic Wand) making plans to attend. Another TI engineer from the Magic Wand team was Mike Read, who used to be known in 4A circles. Mike Read built a stand-alone Magic Wand Speaking Reader, using a TMS9995, I think.

There was a 4A version of the 941 terminal emulator software to connect to TI's employee bulletin board, back in the day. I think the filename was VDT. That would be one way to do it - emulate the server, get a lot of serial ports somehow, hook up 4As with VDT!

You are welcome to it. (but you have a ATmega128 already, why not use that?) The real tricks are preventing read-before-write, and not screwing up the bank register during a byte write. I was able to fit all the logic in a ATF22LV10 which only has 10 registers/combinatorial outputs. (PLD file to be released when it's tested.) I rewrote the code to use LI, which doesn't do a read-before-write, and STST, same. See:

NOTE: The first run of cartridges will be soldered and given out to attendees of Fest 99/4ATX in Austin on Aug 10. Hence the silkscreen logo! This is a 512k Flash cartridge with these special attributes: It has the ability to be erased or reprogrammed on the 4A. It is low-cost. Made for under $7. (assumes Qty 10). It is easy to build. All thru-hole components. 2 socketed chips. Bank switching follows the common non-inverted scheme used by existing mega-carts. Bank is 0 on power-up. The inexpensive TL866/XGecu programmer is used for one-time programming of ATF22LV10, or filling up the Flash. If using the SST39SF040, it provides 4K sectors, so programs can save data in the cartridge. Open source hardware. It supports the AT49F040 (found in UberGROM) or SST39SF040 and similar Flash chips. Fits in a standard cartridge case. Use cases Run the Don't Mess With Texas MegaDemo Run any other 512k cart image With the SST Flash chip, write a game to use a large amount of read/write storage in 4K sectors. Erasing/Reprogramming on the 4A The example code (below) shows how programming works. (Erase is similar.) The AT49F040 must erase the whole chip, with the exception of the first 16k which can be protected. The SST39SF040 is notable for its 4k sectors, individually erasable. When erased, the Flash is filled with 1s which can be written over at any time. It's easy to imagine a scheme where a game could append a little bit of data at a time, and later read from the latest save. Implementation The bank register has 6 bits of address plus two mode bits. It increases the address range to 2^19 = 512K in the usual way. M0 M1 B2 B3 B4 B5 B6 B7 M0 M1 0 0 Read mode 0 1 Command mode 1 0 Program even byte 1 1 Program odd byte Command mode allows the 4A to write special byte sequences to the Flash, for erase, retrieve chip ID, or program a byte. Program mode allows 1 byte to be written to the Flash. Mode bits are cleared after the expected write is done. NOTE: This cartridge will not support GROM. It's simply not possible with the chips on board. Pretty Pictures Those giant parts are actually supposed to be regular size capacitors. I'm having some KiCad difficulty there. Code MYWS BSS 32 PGM DATA >0100 ODD DATA >0080 BAA BYTE >AA B55 BYTE >55 BA0 BYTE >A0 EVEN OPLWPI EQU >02E0 * instruction for LWPI OPLI EQU >0200 * instruction for LI,R0 OPCLR STST R0 * instruction for STST R0 which is better than CLR R0 JUNK EQU >AA55 * Program the flash: address R0, data ptr R1, length R2, bank number R3 (bank*2) * This self-modifying code takes advantage of the fact that LI does not do read-before-write. FLASHW MOV R11,R10 ORI R0,>6000 * ensure R0 in cartridge space * modify instructions for bank number SOC @PGM,R3 MOV R3,@FLSEP * for program even byte SOC @ODD,R3 MOV R3,@FLSOP * for program odd byte FLOOP * modify instructions for addresses and data MOV R0,@FLSEA MOV *R1,@FLSED MOV R0,@FLSOA MOV *R1+,@FLSOD BL @FLASHU DATA OPLWPI * Enter Program mode for even byte in bank R3 FLSEP DATA JUNK DATA OPCLR DATA OPLWPI * Write even byte to address in FLSEA. FLSEA DATA JUNK DATA OPCLR DATA OPLI FLSED DATA JUNK BL @FLASHU DATA OPLWPI * Enter Program mode for odd byte in bank R3 FLSOP DATA JUNK DATA OPCLR DATA OPLWPI * Write odd byte to address in FLSOA. FLSOA DATA JUNK DATA OPCLR DATA OPLI FLSOD DATA JUNK * next LWPI MYWS INCT R0 DECT R2 JGT FLOOP B *R10 * the inner loop is 20 words.. may be feasible to copy it to PAD. Or just 32K. * Byte sequence to unlock Flash for programming. Hardware masks out the read-before write of MOVB, and the unwanted even byte write. FLASHU * Enter Command mode with bank 2 LWPI >6080 bit >80 is for command mode STST R2 set cmd, bank 2 MOVB @BAA,@>7555 flash address >4000+>1555 = >5555 STST R1 set cmd, bank 1 MOVB @BAA,@>6AAA flash address >2000+>aaa = >2aaa STST R2 set cmd, bank 2 MOVB @BA0,@>7555 flash address >4000+>1555 = >5555 LWPI MYWS RT END Risks The cartridge has not been tested. It is being made at DirtyPCBs. It might not be ready by Aug 10. The 22LV10s might turn out to be misprogrammed by the XGecu. (I am verifying one now.)

Similarly far to go is http://www.vcfmw.org/ but in the past there have been carpools from Indianapolis area.

Do you have a LWPI in your program? Normally you don't need one because when started from E/A your program has WP = 20BA Essentially "Load and Run" has already done this for you: LWPI >20BA For instance you could do, MYWS BSS 32 START LWPI MYWS LIMI 0 This will make your program's registers reside in MYWS which you own. It's a good practice, to have your program to set up things for itself. (It might be launched from DM1000 for example) What you should never have is LWPI >83E0 or LWPI GPLWS if you are going to use KSCAN. They will fight. Here is the source to the E/A version of KSCAN. It actually is polite enough to save R11, though it will . GPLWS EQU >83E0 UTLWS EQU >2094 KSCAN0 EQU >21DE KSCAN DATA UTLWS,KSCAN0 KSCAN0 LWPI GPLWS Set WS = GPLWS MOV R11,@UTLWS+22 Save the GPLWS R11 by putting it in our R11, haha BL @SCAN BL uses R11 of GPLWS LWPI UTLWS Set WS = our WS MOV R11,@GPLWS+22 Restore GPL's R11 RTWP

HowDidYouGetTo.cdr

Here's the LS377 latch in the usual bank switched cartridge. The Q outputs hold the bits from the last address written to. (NOT the data bits.) Usually they are connected to the upper bits of a memory. However, they can do other jobs. CLR @>6000 * set Q latch bits to 00000000 (LSBit is not part of latch) CLR @>6006 * set Q latch bits to 00000011 (LSBit is not part of latch) CLR @>61FE * set Q latch bits to 11111111 (LSBit is not part of latch) SETO @>6000 * same result as CLR SETO @>6006 * same result as CLR SETO @>61FE * same result as CLR LWPI >6000 LI R3,0 * sneaky way to write to >6006, Tursi pointed out that LI does not do read-before-write