FarmerPotato

Alright, YEAH! I've heard artrag's results and liked them. Yours is really intelligible once you know what it's supposed to be saying. The intonation and slope at the ends of words comes through, its a big hint to the brain. And, this style would be pretty fun as robot or boss voices in a game. Again, WOW!

Enormous fun I've had laughing along with a chiptune. https://www.youtube.com/watch?v=hk3peGy1v60&feature=share

Oh wow. I finally saw that turkey in the modern era. When it was first advertised in the TEX-Comp catalog, 3 of us (8th graders) pooled our money to buy it. They didn't ship it. TEX-Comp refunded our money. I thought the game had gotten cancelled.

I wasn't the one paying the money, for a lot of things BITD. Thinking back, I don't think I got any disappointments when I spent my own money (Blasto, for instance, or the Markus Weiand Adventure Editor.) All considering, I think $200 for a used CC9900 expansion and 2 DSDD drives, in 1984, had incalculable returns. I still have one of those puppies, reading 100s of disks into Kryoflux. I worked for the summer of 1987 , at minimum wage, straightening pins on salvaged ICs ,and keeping inventory in Wordstar and Lotus 123. That money went toward a new Geneve 9640. Since I used the heck out of it until 1992, I consider it good value. Last night, I found out I can buy a pin straightener for $7. If only I had one back then, I could have asked for a raise.

I guess it would be nice to have a function on the TI end to tell the Pi to 'git pull' or 'git add, git commit'. In case of any merge conflicts, abort and you'd have to login to the PI anyway. That's still useful. I guess Stevie can open the txt as DF128? no DV80 involved? so native format CRLF and all? Then write back to a TIPI disk as native format? For other editors, If the file conversion was managed, I would be happy with a step where the file lived on the PI volume, and I used cmd-line login to the PI to use git. I could imagine a git wrapper on the PI that kept both TXT and DV80 versions. It converts the whole TXT directory over to DV80 TIFILES after a pull. It converts the whole DV80 TIFILES directory to the TXT directory before a commit/push. How I use gitlab now: I currently edit on a PC, assemble with xas99, 'make' into a dsk image with xdm, test in Classic99, commit to Gitlab on the PC command line. So, no DV80 files in that flow. However, with some TIPI in the mix, I could usefully switch back and forth from PC to 4A for any debug/edit/commit cycle. At the very least, I commit the dsk image to gitlab, so it could be pulled onto the TIPI from the cmd line. (but right now I am still loading it onto a CF card with Ti99dir, then using 4A+CF7+. I fried my TIPI with 12V.) Not asking anybody else to write software! If I get my TIPI fixed, I'll try to write that git wrapper (I already wrote a nice DV80 extractor in C)

You could use MESS. I *am* making progress on hardware I feel bad sitting next to a Geneve 9640 not powered on, where I could be trying to keep up with developments. It's exciting what Beery is doing with Geneve sources. My goal is to support existing software with no patches!

This is some seriously impressive translation to our humble SN76489! In flashitback.sid in particular, around 21:14: This song has a lot of notes in the 3rd voice that bend up/down while echoing 4 times. Here is one that goes F-4 G#4 C-5 D#5 four times, while the volume fades from 9F to 04. Since you have a .sid file, is the volume data from a register capture? What if the SID's envelope generator was loaded to produce this effect? In that case there would not be all the volume values in the capture. Do those have to be emulated? (I don't know much about SID, but it has a volume envelope generator onboard. Just wondering.) Also, I see 8 bit volume values. What's the scale for these?

It looks like this is coming along nicely! Do you have an enclosure for the printer?

I have new beige keyboards, but no black ones. (in Texas) I have a beige one in a black/silver console (in Milwaukee storage). I got some heat for showing it in public. Maybe we can swap? (when we can travel and meet up again.) (Old Radio Shack stock I got from a Milwaukee User Group member.)

I was playing Civ V. Oops.

Arg, I missed it.

Cross-posting from IDEA thread: Well, side car and Pbox flex cable are different things, but carrying most of the same signals . The Geneve2020 "hardware compatibility" interface card would have the 16 to 8 bit multiplexer like the 4A, generating wait states, and include the buffers/drivers like the P-box flex cable foot. Then there would be a 50-pin SCSI cable to a new card in the pbox, which replaces the flex interface card. I think of it as the "8 bit compatibility card" and it would supply physical GROM/ROM from cartridges as well on the 8-bit bus. Actually, I hope someone else will make it. (It is totally optional. You get 8-bit vdp, speech and sound from the MSB on the 16-bit bus.) Making a sidecar port might be a matter of same signals, different cable. I dunno what gotchas there might be. How it will work. The memory mapper stores a bit, per page, that goes out over the backplane to indicate an access to an external 8-bit bus multiplexer. It's called the PBPTHP, for P-box Pass Through Page. When a page has the PBPTHP set, is mapped in at an address, say >4000 in GPL mode, and there is a memory access to >4000, the PBPTHP line is asserted. You can also set the PBPTHP on a CRU range. Seeing the PBPTHP, the P-box controller would run the memory cycle out to the Pbox. So, if you had a Geneve/Tipi in the P-box, then you would set things up to assert the PBPTHP when you want a Raspberry.

Well, side car and Pbox flex cable are different things, but carrying most of the same signals . The Geneve2020 "hardware compatibility" interface card would have the 16 to 8 bit multiplexer like the 4A, generating wait states, and include the buffers/drivers like the P-box flex cable foot. Then there would be a 50-pin SCSI cable to a new card in the pbox, which replaces the flex interface card. I think of it as the "8 bit compatibility card" and it would supply physical GROM/ROM from cartridges as well on the 8-bit bus. Actually, I hope someone else will make it. (It is totally optional. You get 8-bit vdp, speech and sound from the MSB on the 16-bit bus.) Making a sidecar port might be a matter of same signals, different cable. I dunno what gotchas there might be. How it will work. The memory mapper stores a bit, per page, that goes out over the backplane to indicate an access to an external 8-bit bus multiplexer. It's called the PBPTHP, for P-box Pass Through Page. When a page has the PBPTHP set, is mapped in at an address, say >4000 in GPL mode, and there is a memory access to >4000, the PBPTHP line is asserted. You can also set the PBPTHP on a CRU range. Seeing the PBPTHP, the P-box controller would run the memory cycle out to the Pbox. So, if you had a Geneve/Tipi in the P-box, then you would set things up to assert the PBPTHP when you want a Raspberry.

Wifi/TIPI is very up in the air and a long way off. I did ask JediMatt42 if it was OK to incorporate TIPI, and he said "its open source", but I would like to have everybody happy. So I ask first. I would like to use TIPI as the internet solution, because it is already established. Wifi won't be built in, because a WiModem or ESP8266 would introduce an additional microprocessor that far outclasses the 99105. (If I need a coprocessor, I would go as far as a 9995!) But if you have your Pi externally, that's ok with me. So what I will look at it is absorbing the TIPI into the I/O card, at the expected addresses. Some modifications to the DSR might be necessary, but that's doable. it's a ways off. Connectivity on Geneve2020 first will be FTDI cable, RS232, and 2 MMC card slots standard.

I went looking and found this company, which makes them for a reasonable price: https://ganson-store.com/thermal-labels-cut-sheet-labels-pin-fed-labels/fanfold-labels-for-continuous-form-printers/ Happy memories of using my box of 500 labels for a decade.

Mind blown. I would never have thought this possible!

Some more fun details: The system uses a Eurocard backplane with 8 Eurocard slots (160x100mm). 4 slots will be filled by CPU/CRU, I/O, FPGA/DRAM, and Video/Audio. (I'm actually making them separate, first.) The EuroCard bus is compatible with retrobrewcomputing.org I/O cards (but not memory). The CPU card maps a range of CRU byte-parallel operations (LDCR, STCR) to the I/O cycle typical of a Z-80 or 8086 (asserting the /IORQ pin). For instance, the DiskIO/3 card, built for a Z-80, could be addressed by CRU. DiskIO/3 provides a u765 floppy chip DSDD, and IDE interface. It's my hope that I can leverage that DiskIO/3 card, and in the other direction, give something back. Other far future expansion cards are a P-Box interface, for ultimate compatibility.

A short status update for June and July. I've put a great deal of effort into mechanical and thermal design. The goal is to produce an affordable metal enclosure for a complete system. While also preserving the ability to put the electronics into a PC ATX case. I'll have photos of the actual thing soon. I've used PC97 motherboard-to-port header pinouts wherever possible. So there is a chance that in an ATX case, the standard PCI card brackets will be usable, for plugging in PS/2 keyboard, mouse, RS232, VGA, etc. I used the AC97 standard audio, 10-pin motherboard cable, to the front panel audio jacks. But my enclosure provides all those ports in its I/O panel. I was inspired by FRONTX.COM. The whole system will fit into a 10x8x5" steel enclosure, with power supply and fan, adding about $100. That's not unreasonable for what you might spend on a new PC ATX case with power supply. But you could still bring your own ATX case. It needs the 20-pin ATX power connector, and one 4-pin "Molex" power cable. The CPU card is built and running. It doesn't do much without memory or communications. The PCBs for those are awaiting a serious QA review. When those are made, the minimum viable system will be ready to test and debug. It will have serial console (DB9) and PS/2 keyboard/mouse and 256K of static RAM. Everything else is still in a design stage, like the 32MB memory card, FPGA, SD cards. I had my technician make the IceZero, to prove we could build a board with a TQFP144 chip, 0.6 mm pin spacing.

Aha, was your point was the latched outputs would help in creating a loop-around multiplexer? Or just that chips can be found?

Nice setup! What brand/model is the hot air station? What Hakko tips work best for you? The blue thing by the wire cutters: is that a solder-sucker? how does that work for you? WHERE IS THE FLUX? you can't have too much flux.

It's complicated. Documents show a steady evolution through 1982-1983, from 99/4A QI, to using the TMS9995 for the 99/4B then 99/5. Constant interaction between Don Bynum, Ron Wilcox, Mike Bunyard and some others. They kept fluctuating price lists of CPU, memory, and PAL chips. There was a budget upper limit, so that manufacturing a 4B or 5 would cost the same as the 4A QI. Components were around $100. During 82-83 the prices of DRAM dropped rapidly, to the point that 16K more of CPU DRAM was added. I don't know when or why the engineers transitioned to a much more complex 99/8 design. Maybe it was the desire to segment the price points between 4A and 8. See the Docs thread, where a lot of this is posted, or WHTECH.

I used Draw-A-Bit on a school project, to draw bitmap screens. It had a lot of overlay code on its disk so you couldn't remove it. Since each save file took 49 sectors (bitmap mode) you needed a second disk for saves. But it was distributed on 1 SSSD, I think. Maybe the printing program was sold separately, but it would fit on Disk 1. TI-Artist... if you wanted fonts handy, there was no upper limit! I resorted to having TI Artist in one drive, and swap a fonts disk and my save disk in the other. I think I settled on 1 or 2 fonts and just copied those to my save disk. My friends and I spent a LOT of time designing labels for floppy disks and booklets. It took years to use up a box of 250 Avery disk labels, but it finally happened.

I remember a lot of Apple ][ graphical adventure games that required 2 or more disks. That doubled the possible images. You'd switch the disk at one point into the game, but switch back when you returned to the early areas. One that I recall was Mask of the Sun (Apple ][) which had a long sequence of scenes that played while Raoul was driving your car around a mountain road. They had plenty of space, so why not. But other than Return to Pirate's Isle, I don't know of any for the TI. Does Tunnels of Doom count? We had cartridge ROM/GROM unlike other micros.

I think BBS would be in the category of "requires 2 drives". At least! Though, Techie (Monty Schmidt) and TICOMM (John Clulow), at least in the versions I saw, worked fine with one disk. My TI-Net BBS software assumed 2 drives, DSSD (TI Controller). It came on 2 DSSD disks. The program would be in drive 1 (it would run game programs, so it had to re-load the main BBS after that). Messages and other files could be on either drive. You could also move the assembly routines and LOAD to their own disk, because they weren't needed again after the first startup. (saves 100 sectors of DIS/FIX 80 uncompressed object code.. later I used Barry Boone's SYSTEX to squish that down.) Matt Storm and I both had the CorComp mini-expansion system with 2 drives, so DSDD. His BBS ran on that hardware, but I ran my BBS for a while with a P-Box, TI disk controller and 2 half-heights, I think.

All the InfoCom games. The interpreter and first game file were loaded into memory from disk 1. The bigger, random access game file was on disk 2.