acadiel

Wow. I’d love to see internal pics. Mine works, though. :-)

Ya know, it works very well, and once you get the hang of it, it's super easy to use. @Tursi did an awesome job.

Something to think about. The Hexbus data pins were used to write to cassette on the TI-74. The routines were in ROM on the 74 for this. I wonder how easy it would be to create a small assembly routine to add the same cassette routines to the CC-40. It's kind of an academic exercise because we have the SD card interface, but it would be fun to create a simple Hexbus cassette interface and an assembler routine you could put in RAM for cassette storage. Unless this will only function as part of the CPU ROM.

Yep, my workflow for UberGROM carts from scratch (if I remember it correctly) - More details are here. ROM: Divide 512/ROM_SIZE (8K, 16K, etc) to determine how many times I need to duplicate the ROM Duplicate the ROM that many times & concatenate it. I wind up with a 512K ROM. Burn the 512K ROM to a 29F040 or 49F040 GROMs in 1284P: Divide GROM into 8,192 or 6,144 byte sections. I always strip off the AA01XX header. Call them _G3, _G4, _G5, _G6, _G7 at the end Copy those files to a USB drive (HFA floppy image) with TI Image Tool (make sure GROMCFG is also on this disk) Move my USB key to my GoTek attached to my TI-99/4A Run the built in EA on a new UberGROM Run GROMCFG and load the GROMs onto the UberGROM (GROMS 3-7 as applicable - do NOT Skip GK header as these are already stripped GROMs) Test it out If it works, dump the 1284P in a programmer and you'll get a 132K image for the 1284P. You can then distribute that to others with the 512K EPROM. I believe that Tursi has ways of constructing the 1284P image from within Classic99, but I don't know what the method is.

Yup.

My Corcomp Mini PES sidecar had two issues with it crop up about five years ago: the PSU went out (which I found a good one - it had the same type of voltage requirements as the console replacement PSU I was using), and the 9901 for the disk controller board went out. What’s strange is that nothing was plugged in incorrectly, it just stopped working. That reminds me that we need to make some new disk controller boards for the Mini PES systems - a lot of them are missing the disk controller boards because they weren’t ordered with them.

Nicely done! I’m so happy that you’re in the community now! 😀

If you want to email me a manual, parts list and a high res pic of a finished board to me, I can get on Mouser and build a BOM. I'll let you review it, and then if we're good, I'll replicate it on DigiKey and others can also replicate it on their favorite electronics site.

I have three recorders left if anyone still wants one. Let me know.

We might want to put a BOM together on Mouser or DigiKey if one doesn’t exist already. Ksarul, let me know if you need help.

We need a clearer graphic about wiring orientation if someone wants to make it (and is good at graphics). I even got confused.

@arcadeshopper - Was it that set that someone on Facebook had posted recently? That's a really cool homebrew set of carts. Like Ksarul said - having it split up like that is kind of cool.

I do see wires hooked up to (on the 2564): 1 - Vpp 2 - Cable Select 1 14 - Vss 27 - Cable Select 2 28 - Vcc We're just dealing with CS1 and CS1, ground and +5V here. Usually, with those two cable select pins - they are invoked to power down the EPROM or make it active. My guess is that they're just hooked with all those wires in that they conform to the truth table to keep the EPROM active. The rest of the pins support a standard 8K 2564 24 pin EPROM.

Do ESRs matter with any of our capacitors? In some of my old computing equipment, I really hadn't noticed it mattering, but some folks have been super vigilant about making sure. I saw someone made a DigiKey BOM - perhaps we can make a Mouser one too and our European friends can make one from a supplier over there. I have replaced caps on a lot of 80s-2000s equipment in the past not knowing about ESR - just using high quality capacitors, and everything is still running just fine. Some of the fun things in 80s equipment are the RIFA caps from the 80s that go into flames and let the magic smoke out (these are the high voltage across AC). Aren't you glad we don't have these?

Not meaning to necroressurect a thread, but I got a nice reproduction of the Heiner Martin 1985 cart board in the mail from Mantadoc. It has two spots for 2764s along with the GROM logic ICs. Does anyone know which ones of these were GROM and which was ROM, and what the original use cases of the 8K GROM + 8K ROM was? I see people made glorious modifications above to 128K and 256K, which is awesome.

It’s larger than the other one you disassembled, running around 6K or so. Probably had additional functionality. It was shoehorned into the same PCB and had extra wires soldered from the 8K chip to the PCB. Atrax, can you get us some good pictures from Lee?

I think that in the spirit of Omega's original question - creating transparency for the user is probably the key first and foremost. In XB, RXB, SuperXB, etc, those can likely be modified to where you type SIZE, you get a whole hunk of memory that XB can handle from SAMS (including the 32K space at >2000 and >A000). I know RXB has a lot of that support for SAMS already. Depending on the availability of XB and SuperXB source (Triton SuperXB, the German Silver and Gold carts, etc), we might or might not be able to modify those if people want to use different varieties. Turboforth, from what I read above, seems to support SAMS. Assembly is a little more challenging. You are already programming bare metal, and a lot of coders have their own subroutines already made that they include in their programs. If you're used to doing that, for a "beginner to immediate" skilled assembly programmer (which would be me), I'd like to have some standard types of subroutines for SAMs that I could easily call already written - I just stick them in my program. Expert assembler programmers like Tursi, Mark Wills, and others write their own optimized code and know how to optimize every single last bit for brevity and performance, and likely already have some subroutines in their code we could use (if they're programmed for SAMS yet). You can see some rudimentary bank switching "trampoline" type routines in the source code for 16K and above ROM carts. John Phillips' The Great Word Race, Strike III, StarGazer I/II/III Combo cart, and others have source on WHTech that have some of his bank switching code. He had two types of bank switching code routines: CRU and "Write to ROM", and he reused the same code in his assembly for those types. As far as native OS support - for the basic console to be able to recognize something above >FFFF transparently, the GROM/ROM in the console would have to be overridden by OS code that knows how to bank/handle transparent access to those addresses, such as >10AAA. And I'm guessing E/A and some other programs would also need to be patched, because they're used to the 64K memory map. Since the 9900 hardware likely doesn't support it, the software layer will have to translate to the 64K "window" so the 9900 can do whatever it needs to. I'm sure other 16 bit consoles are out there that figured out how to break out of the 65536 bytes of RAM by paging. I just don't know what they are. I'm sure I simplified things way too much or didn't use completely correct info above - I'll let the more seasoned developers correct me as needed

IMHO, as an option, I'd like to just make a board for the Meanwell that lets you: * Hook the female 5 pin DIN connector with a PCB that fits the PSU hole on the back of the console * Make a board that fits on the inside of the console with a switch. We would have to figure out a circuit that handles triple pole switch that fits into the switch in the console *or* a 5V triple pole relay that the switch controls. That's all that would really be on this PCB. This would be insanely cheap. You're only paying for a BOM of: * 5 pin female DIN * PCB rectangle board for the DIN * Four wires from female DIN PCB to switch PCB * Switch PCB with either: ** Triple pole switch -or- ** Triple pole relay and single pole switch * Four wires and connector to motherboard And of course, the Meanwell PSU. I haven't specced out anything yet. But the triple pole equipment is bound to be fun to find.

Nice!!! I'm always impressed when I see a writeup like this. They honestly spent a decent amount of time doing it, too.

I still have two of the cassette recorders left. $5.35 (or something like that) plus postage.

That's pretty awesome! Michael Becker did say he did 'improvements' to his prototype model, so the PAL might be different. I'd be curious for someone to look at the three GAL's code that I uploaded to see what they do.

Do you think you can dump that PAL that I couldn't on the proto unit?

Yep, 5102 - I'm bad. Even the schematics say that. LOL. I think Michael consolidated a lot of the logic chips in the design. GAL20V8A-25QPI *PALCE610H-25PC GAL22V10-25LPI GAL16V8A-15LPI DSR ROM: 27C512 The PALCE is the only one I didn't dump that's in that zip file. Also, I was told that this was an 'improved' design by Michael, so it must be different somehow.

Here is the Michael Becker PHP1300 images (these are as high res as I have). I posted a lot of the PALs and dumps earlier in the thread. This is the standalone PHP1300 interface. Ksarul is the owner of it, currently, and will have to dump the remaining GALs/PALs that I couldn't.

Great job! Any idea why there were three RS232 device names in the DSR? What is done in the code with them?