wierd_w

The idea is to use a more modern SRAM. Much of the space is taken up by the sram modules, but there are more dense modules to be had these days. I was thinking more along the lines of a TSOP socket on a solderable DIP. Price would go WAAAY up, but still. Failing that, go ahead and just use tsop packages with SMT mounting like they are intended.

Hmmm... Outside the box solution: One of these inexpensive backplanes... https://www.mouser.com/ProductDetail/Advantech/PCA-6105P3-5A1E?qs=HovGnFcXeQCTm1XmLEYbdw%3D%3D With one of these SBCs (which has an FDC!) https://www.bsicomputer.com/products/wsb-h610-full-size-cpu-card-2864 That would give you a modern class computer with a real floppy disk controller. It would also give you some ISA slots for whatever you might want to put in there. You would need a special chassis though.

OK, another "Wish I had..." Option. 44pin interface (EG, after a JediMatt 32k card and Tipi) SAMS. (I can envision how SAMS can be expanded even bigger in a more or less back compatible fashion*) Not all of us have the desk real-estate for a PEB, nor do they want one. * Basically, you put a better mapper on, with an opaque latch driven by the data bus in addition to the CRU bus SAMS currently uses. You do this by marking a small slice of RAM as reserved for the banking register, and do the writes there. When the correct address lines (for that location) and WE are hot, the data bus latch enables and catches the data written to control the mapper. Each additional bit gained exponentially increases the banking space. Since switching can still happen in the original SAMS methodology without the special writes being done, it would be back compatible. Just if you do the special write, you basically "Bank out the set of banks". At least from a logical perspective anyway. 8 bits of additional latch should bring the theoretical max banked memory up from 1mb to 256mb.

I was planning on doing this very thing in the near to distant future. (Still waiting on shipment of the adapter.) 2 DB9 female, 1 DB9 male, and a 5vDC barrel connector, on a protoboard, in a 3D print shell. Bob's your uncle.

While drawing a title screen prototype for FarmerPotato's upcomming title, I noticed that with it shrunk real small, it looks real sharp. This made me have a strange idea, when I considered the FPGA Ti 99 project cited in the develpment subforum... Small Ti 99 handheld. (think about the size of the original gameboy, but a little fatter in the 'depth' direction, so full size carts can go in.) There are tiny vga (and composite) screens you can source for such a thing. It would make a neat project I think. You said the most radical, so there you go.

DS, 2DS, or 3DS? (and which revision of the console) Ninty does not like the flashcarts. There are multiple devices, for multiple generations of the handheld.

How about amazon? https://www.amazon.com/Panasonic-LS120-Beige-Bezel-LKM-F433-102/dp/B0045JPK7K/ref=sr_1_50?keywords=LS120&qid=1571056034&sr=8-50 Or NewEgg? https://www.newegg.com/p/2M6-000V-00004?Description=LS120&cm_re=LS120-_-9SIAA7W8VH8393-_-Product EDIT I also found this, concerning your TEAC SCSI units. https://hxc2001.com/download/datasheet/floppy/thirdparty/Teac/FC1/HW_HS_1100.PDF It appears to be a very detailed user manual for the scsi controller and disk combination you have, and includes the jumper info. On Pg11, it discusses the various formats of disk the drive and controller supports, and what "mode" to use. For high density diskettes, this would be the "2mb" mode. They are clearly referring to "unformatted capacity" for size. Their table lists 1.20mb, 1.44mb, and 1.62mb formats in this configuration category. (I suspect that the 1.72 variant of the microsoft distribution formatting is not supported?) Jumper configuration information begins on Pg42. It looks like the controller expects to be told what kind of floppy is inserted or something. (PG40) There are two cited methods for getting the drive/controller to identify the disk type as the 2mb variety, and they both seem to involve scsi messages being sent. I am beginning to think that the LS120 is the better option--

The one I got (and have set aside, since it has more snow than a blizzard on a mountain top) is a UM1381. They seem to be quite common. What's so magically special about this TI-900?

That latter is quite interesting. Rather than controlling the speech synth, I think it would be more interesting to EMULATE it. Especially with a Tipi. One of the things I keep reading is how power-hungry a speech sidecar is. If you can avoid having that on the expansion, it makes sense to me...

Basically, Steve Jobs visited XEROX-PARC, and saw the future of computing there. That is why Mac was pushed, and IIgs was sidelined. (the IIgs was a very good computer for its time) http://www.righto.com/2016/06/y-combinators-xerox-alto-restoring.html

I doubt the SRAMs inside could stand up to the ionizing radiation of the 3 month trip (best time) to get there... BUT-- the TI does have a reasonable power footprint (once you cut out that sinfully inefficient transformer)... I wonder if my "Nuclear powered laptop" idea would work... (Not really as scary as it sounds. Just a bunch of tritium gas containing sign illuminators and high efficiency PV cells.)

Some digging gives me some benchmarking that helps confirm my hypothesis of using RPI gpio with python. https://rpiai.com/raspberrypi/gpio/ The benchmark done suggests that the python libs are (at best) ~20x faster than the minimum required signalling speed of 3khz. (close to 60khz max write on gpio pins with python) That gives ample room to set some modes and introduce wait-states. Reading is slower (some arguments I have read say 3x slower). It may be necessary to implement a transistor based hold for the messages if the hexbus shoots them too quickly to test reliably. (I am thinking a set of logic gates that sets 2 flipflop arrays to all zeros before disabling themselves (logic gates) when BAV goes low, catches the first nibble than does a NAND against the stored value(s) to catch when it changes (when it drops the data pins it would go all 0s, which would trigger the switch before the next nibble arrives), switches out the flipflop array with another one to catch the next nibble, then present the whole word to the PI on the GPIO pins. This would effectively double the time allowed in which to read the values being sent, and would hold the message bits sent until the next BAV cycle. The bus master holds BAV low while it is waiting for a message, if I am reading correctly. I could thus use BAV-LOW as a signal to sustain the captured message, then reset to all 0s when it goes back high.) I could implement those with some bog-standard transistor package ICs.) Other than maybe needing that buffer, it looks like a python script on a Pi would be sufficient. C would be much faster, possibly eliminating the need for the buffer circuit (if it is even needed in the first place), since reading and writing on the GPIOs is closer to 50mhz when done with compiled code-- Just that is less approachable for hacking new features on later. (If I WERE to undertake this, I would want to use some of the reserved ID space-- [TI is NOT going to release new peripherals in that space!]-- to implement 3 new device classes; PCM wave device, tone generator, and midi device. This is because there are zero audio devices in the CC-40, but with the Pi attached, you would have a display device, disk device, and an IO device. Might as well have an audio device as well. The lack of storage has produced a dearth of incumbent software, so such a solution would quickly become the de-facto standard for making these things do fun things, and giving the option for audio seems sensible. Using the Pi as the audio renderer makes sense; It would also be the enhanced display device, and would output over HDMI to a connected TV. For PCM device, since sending samples all the time is very foolish due to the way the bus works, creating a "wave sample hold, play sample on demand" implementation seems appropriate (Think a software-based, stripped-down version of the SNES SCP. Hell, we could GIVE a software SCP if we really wanted; That would turn it from a PCM device into a sampler device, with pitch, sustain, reverb, and pals). That way a program would first feed its samples into the PCM device into some playback banks, then it would just blurp out a message like "Play bank 1" when it wanted to make that sound. It would need commands to store a PCM sample, to play a sample, and to delete a sample. Tone generator and MIDI device are pretty straight forward. You just send message for either sinewave type, voice number, value, volume, and duration-- for sound generator-- or just forward a raw midi command word for the midi device. There's apparently community desire to make these small computers do fun things, might as well give a full toolbox.) It is this potential for easily hacking stuff on that makes python attractive. It looks fast enough for function while being transparent enough for easy hacking.

Hmm.. I bet I could make a quick and dirty font. (Fontforge should be sufficient... I could trace the outlines with my CAD software and import them.) Do we have more resources for this font? (Need more use examples to get all glyphs and kerning pair data)

I am reading the hexbus specification document. From what I am reading here, a computer on an LPT port could fake being all manner of devices. Alternatively, an SBC with enough gpios (like a beaglebone or an RPi) could do the same. The HexBus communicates in 4 bit nibbles, with 2 additional signals to control bus activity (BAV and HSK). It uses a packet communication format that is dirt simple. A genuine LPT port is basically 8 GPIOs, with some extras, which is more than adequate for this purpose. Emulating a storage device to be able to get and send data to/from a CC-40 over an LPT cable looks doable. Because it uses a packet communication system, and the kinds of operations that can be sent are abstractions for something a computer would be needed for (Literally, one of the command messages is "Open a file"), you would need either a robust microcontroller, or an SBC to effectively communicate on this thing (in a portable manner. Again, a PC with a real LPT port should also be adequate at the lowest speed mode). Thankfully the command set is very limited (255 operations + the null operation). I think Python can handle RPi GPIOs sufficiently quickly to be able to make a hexbus communication library. (The specification says that the HSK signal can be held for as long as 20ms, and that the minimum In-Spec transfer speed is 3000 bit/sec. I think RPi GPIOs can go that fast, and if not, then the PWM pins could, you would need only 4 of them) The way the bus is designed, multiple devices can be attached to the bus at the same time. The system differentiates them with an identifier value in the packet. All messages are brokered by the master of the system; If a device wants/needs to get the system's attention, it pulls HSK low, which prompts the master to pull BAV low, then poll for devices it has registered as being allowed to call it in this fashion, by sending packets in a sequential manner addressed to each device it has registered. There is also an option for the master to relinquish control of the bus, and give it to another device. Reading the list of device IDs and their role allocations, one set is for having multiple CC-40s connected to each other. This message is for the purpose of the slave CC-40s to give control to the bus master, so that they do not attempt to manage the bus. Since all devices listen to the control message preamble of each packet sent by the master, (To see if it is addressed to them), then a device sitting on the bus (Say, something like a "TiPI for hexbus"...) could respond to multiple device IDs, and (To the CC-40) appear to be several distinct and separate devices on the bus. It could thus simultaneously be a disk controller, a display device, a serial port, and a printer -- for instance-- all at the same time. Since no two devices ever communicate at the same time (since the shared bus's nature is ALWAYS master-initiated on all transactions), There's really no reason that this couldnt be done. A raspberry pi could be the single device you ever need to connect to your CC-40, which would then provide service roles for basically anything the CC-40 was designed for. (Including attaching a display (Device codes 30 through 33 are earmarked for color television display device and 40 through 43 are earmarked for black and white television display device.) -- the idea here is to use python and SDL to create an opengl rendering pipeline that produces output on the pi's hdmi lead, based on the command messages received-- and RAM based file devices (IDs 240 through 244 are reserved for "RAM file manager"); You would tell the pi to create a filesystem with zram or something, and then work with it using the command set.) The real limitation would be the selection of DSRs baked into the CC-40. If I had one of these things, I would start working on a Raspberry Pi software-based solution. For reference, the hexbus specification is here: http://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus Specifications.pdf Sadly, I don't have one of these little toys to play with (and really don't have an urge to buy one. My curiosity is sated just by reading this spec document.)

And Yup- that is surprisingly similar to the RAMBO. Just with larger pages, and more total pages. Also does not abuse CRU writes. Abuses normal memory writes instead.

The idea here would be to replace the one-line assembler with the EMS routine, but otherwise give a modified mini memory cart, including the DSR. The DSR would reference the EMS routine to handle page switching, and could provide a fantastically huge ramdisk, if the user wished. alternatively, the EMS-like page routine could be called by user programs, to use the vastly expanded memory capacity for other purposes. (Such as disk based games, like the CRPG that spawned this discussion.) OR both at the same time, since the handler baked into the cart should be able to keep track of its own allocations too, and report how much free spaces is not used, and present that to programs. (The calling program does not need to know specifically what pages in the space its memory is on, only which page that is allocated to IT it needs to access. The handler keeps the total accounting.)

Or you just need a standard for memory allocation. That would be more in line with how hardware EMS worked on XTs. You have a handler that does the paging for you, and keeps track of allocations, and by what programs. When a program wants memory, it sends a request to the EMS handler, which then moves the window for it. It then reads on the pageframe like normal. The program just has to be mindful to always notify the EMS handler when it wants to change the page. Something similar could be done with the TI without resorting to exotic MMU implementations.

Yup. That's why you would need a shit ton of CS lines. (Small banks == more banks needed). If you catch 2 bytes being written (16 bit write), that is 65535 possible values to select from. Or, at a 4k window (since the cart has a ram window and a rom) that gives ~256 mbytes. Basically like a souped up mini memory cart. It would take a pretty scary number of flip flops wired in at the bottom of the ROM area to do the catching, and the SRAMs would be pricey, but I belive it would work.

Interesting... Do any of the existing devices out there (FG99 etc obviously wont do 16MB, but there are others out there) support this operation mode? An emulator feature is one thing-- I was contemplating a hardware device.

I have often wondered if SAMS could be implemented onto a cartridge-- or at least, something similar to it. The normal latching system to bank switch is all fine and good, but you need a way to generate additional chip select lines. I figured I could do something 'like' that, by using the WE signal to temporarily disconnect the attached rom, (The bus cannot read while performing a write anyway! We would only do this if the correct address lines are raised as well, that way we know we are catching a bank-switch message), and connect a small series of transistor flipflops to "catch" the byte being written. Once the WE signal drops, you re-attach the rom's address lines, then attach the output of the flipflop array to your latching system to drive/provide the missing chip select lines. If we catch several BYTES worth of written data, we have an epic crapton of software selectable CS pins that we can generate from them. That way, even with a small window in the address space we can tack on a buttload of potential ram banks.

Neat. I figured such a thing would have to have been made at some point. Concerning a disk controller.. Bitbang'ed SDCard is probably doable. (You can talk to an SD card on 2 pins, if you can control them individually. From a cursory browsing of the pinout of the hexbus, it appears to be a parallel type interface, so driving two of the leads in the correct fashion seems doable in theory.) OH YEAH-- A thought occurs to me! There's a serial connection style floppy drive that was used with knitting machines. (Conveniently battery operated!) It's a little bit bizarre in that it only uses a single side of the diskette, and is pretty limited capacity wise-- But then again, the CC40 isn't exactly a supercomputer anyway. It's basically the same drive as was used on Tandy 100 systems. Since it is a serial interface, something could possibly be done in the form-factor of a custom hex-bus cable. (An IC, --possibly a microcontroller of some kind-- that sets up the hex-bus for the CC40 and pretends to be a wafertape drive, then brokers all the transactions with the diskette drive-- could live in a little plastic package inline on the cable.) Capacity wise, it is probably similar to the wafertape drives, so emulation of one might be doable. (With the benefit of being more reliable than a tape, with faster seeks) There is one currently available (but pricey) on ebay right now, but you would probably have to get it before one of the old knitting ladies does.

It's disk based for a reason I understand. (You load and unload assets/program data. FinalGROM puts a big chunk into memory and does simulated bank switching. Only so much you can fit with that.) Just advise them to get a nanoPEB or a TiPI. (shrug) I want to get an F18A sometime this year. (If I can manage to find one that is. Nobody seems willing to part with one. Can't find one for sale anywhere.)

They aren't hard to find (unlike F18As... I cant seem to find anyone with one for sale.), I got one off ebay pretty painlessly. When I get my sidecard TiPi, it should be all good from there. (Still waiting on ArcadeShopper to mail it.)

I did! Looking good so far! Looks like we need something to shoot. (both ammo and target.) Painful to control with a keyboard though. No reverse thrust option.

(NM, figured it out. F18A was not turned on) Looks like I need to get on the stick with making some background goodies, and getting some enemy sprites made. Also, looks like I need to increase the shade level. Either that or JS99 is washing out the color.