9640News

There was a comment I heard this card may have used a daughter board, and some of those eprom versions required the daughter board. Beery

I have the SCSI card shown below. I'm using it on my Geneve. Tim mentioned there may be an update for this board? It is a Revision F, Serial #74, with a V1.1 eprom. Thanks for any feedback, etc.

There are also some ABASIC games including Global Wars and Barricade (?) Mike Riccio posted I think a MDOS tetris game, and there is also Klaus Gebecke's Tetris game. Seems like I saw another game or two in Clint Pulley's c source package recently. Beery

Just posting an update here. Today, I burned the first eprom with the new TIPI code. This was code from the 0.98 eprom with the new TIPI code and a TIPI specific LOAD-SYS. Screen displays the swan, and loads MDOS from the TIPI. Takes about 20 seconds to load as everything must pass through VDP as it is loading 32 sector chunks at a time, that then has to then be copied to CPU ram. Right now, the only downside is the Swan display during the load process is corrupted in two spots as things pass into the VDP. I think I will need to dump the Swan which was my original intention in the first place, however the VDP setup for the Swan is doing something I haven't understood yet from the earlier VDP initialization that has prohibited the display of any other screen I tried to display. Anyways, wanted to give people an update.

That's what my wife said about me!!!!

In the example on the left, you got the device error because you typed "module", not "modules" with the latter being the correct folder name. And sorta along the lines with what was posted above, the trailing slash was after the directory name was converted to a period so that "modules" became "modules." which that folder does not exist either. The CMD.exe window for Win10 allows one to: cd down\ to go to C:\>DOWN or cd down. to go to C:\>DOWN One route would require stripping a trailing "." or trailing "\" from the path request. Another option is to strip and error report and revert back to the original path if an invalid entry is made similar to what a MS-DOS prompt would do. This is worth documenting as an improvement "as time permits" as it would likely require changes in a number of places in the CLI code for consistency sake across a number of commands impacted.

I'm trying to remember the name of the TI-99/4A program that used the 9938 chip that Alexander Hulpke wrote. If you don't find a Myarc manual, that program should have had documentation and I think the features were near identical. Beery

Rich, Not sure at what point you are starting from, so here goes. If your TI system has a floppy drive, you can copy files from the floppy drive to the TIPI with a program like DM2K. When I specify the TIPI with DM2K, I use the device name of DSK0. Now, if you want to say move files from say Atariage to the TIPI, as mentioned earlier, you need to have an IP for your PI so that you can do what I would presume is a wireless connection from your PC to the TIPI. The login name and pwd are both "tipi" with no quotes. Once you have logged in, you will either be logged in at the TIPI root directory which is where you would drop your files, or up one level above that that would have two folders, "PDFS" and "TIPI". The folder PDFS is where files go when you print to PI.PIO. Click on TIPI to get into that folder. If you are at the TIPI folder, you can create as many directories as you want, and populate each directory with as many files as you want. Keep in mind there is a buffer limit for DM2K (~230 maybe) that it will see first. At one of those two paths, I would map a drive letter to that folder on your PC. That will then allow you to use TIDIR to browse the TIPI. One screen tag the files you want to move across to the TIPI. Make sure you set the configuration option so that when you copy files, you drop the files to the TIPI in TIFILES format, and not V9T9 format. I'm not sure if Matt has on his WIKI has the detailed information for the PI.CONFIG file on the sort order for files on the TIPI. There are three options for the sort order in a config file. If you don't like the default sort order, then ask and someone can answer.

I've got a request for something that I think may be along a minor tweak for TIDIR as I think the core routines are already present. I am testing Github as a repository for TI source files for assembly on a Geneve and/or TI-99/4A. Uploading files with TIFILES headers is not a problem, just the file can not be viewed on GitHub if someone wants to view the file. Please note these files are originating from a TIPI share but could just as easily original from a source file on a DSK or HDIMG file. It would be nice to convert a mass of directories of source files into text files at a second path with preservation of all TI formatting including tab spacing, that could then be uploaded to Github, and then if someone downloads files, those files could then be converted back to a D/V80 file with a TIFILES header maintaining the original format. I am not entirely sure if GitHub will default to a TXT viewer of the file if there is no extension of the filename, so that may be a requirement. I would also suggest that when reading the TIFILES header, if it detects a DIS/FIX 80 file or a Program Image file, it copies but treats those files as possible binary files with no file manipulation. From what I can tell, TIDIR has the capability, just a tad more involved. What I was hoping what could be done would be to have a GitHub option on the menu bar with two options, Convert for Upload, Convert back from Download. Then TIDIR would store the configuration parameters for file format (DIS/VAR 80) with the appropriate CR/LF requirements, without having to remember all the specific details. I think something along these lines would allow us to create more easily source file repositories for those individuals not using compilers and assemblers that use a .text format on other platform computers. Where I have also seen issues and I know there is not an easy solution, is on those other platforms, individuals have used the true tab character in their spacing that makes converting back to a clean and neat DIS/VAR 80 format for the TI more difficult as our editors treat the tab character differently than the way we may tab while programming. Thus, the first goal would be to handle a DIS/VAR 80 source file option for moving files around. I am looking for point click, highlight, select transfer option, watch and wait, and it is done. Beery

I wholeheartedly concur as it allows me to move files from whtech, atariage, or my BBS over to a directory on the TIPI by using TIDIR with minimal effort. Things are a snap now versus what the route to move things around a couple years ago. Beery

Just booted MDOS with a TIPI from a simulated eprom. I've been banging my head trying to understand why one PAB for the HFDC worked, but not the TIPI PAB. Turned out, both PAB's were right after one another in the code, but not separated by an EVEN instruction. Then, the TIPI code tried to do a MOV instruction on an odd boundary causing the issue. Thanks to Tim's suggestion to use his RS232 "debugger" type interface for output, I chased the issue down. Only took about 4 days............. Beery

Got a question. Does the LOAD opcode >05 return anything to the PAB in VRAM beyond the status byte for a Program Image file? Would the Myarc HFDC return anything more? Perhaps the program start address and length of file? This may be something very specific to the Myarc HFDC. I've not been able to find any specific notes on the LOAD opcode, and an example of a file I am using suggests there is more going on. Beery

What is not predictable?

Well, very few people have looked at the code for MDOS, however in my opinion, it is probably one of the finest examples out there. Until you really start digging into it, and boy do you have to dig into it, but it is truly amazing everything that is in the code. The code requires approximately 22 x 8K pages of memory with 6 memory overlays of extended libraries that can talk to the other libraries, a "Shell" called the Command Line Interpreter or MDOS prompt that can do just about any disk management feature one can imagine, and supports TI/Myarc/CC FDC's, RS232's, a SCSI card, and soon to be released IDE and TIPI cards as well. Some of the code can be difficult to follow as there is so much memory paging involved and several examples of various object files using the same label code in their sources that can be confusing, however, IT WORKS, and it works well. It has a single DSR while in "TI-99/4A mode" that pretty much if you can plug it into the PEBox, it will talk to it with very few exceptions of incompatible hardware. That same DSR is smart enough to know whether you are calling it from TI-99/4A mode, or MDOS mode. And in MDOS mode it can really unleash its power. Imagine in about 5 lines of code, being able to change to any of the text or graphic modes, load or save a file, or call any of a hundred or more routines without adding all the extra VMBW, VSBR, DSRLNK, etc. code to your source. If you want to write text to a graphics screen, you don't need to figure out the character pattern and where to write each pixel. You just give it the string and call the library function and MDOS does it for you. If anyone ever wanted to learn assembly language, I would tell them to start off with programming in MDOS mode on the Geneve as those XOP (library) calls gets you well on your way with minimal effort as you learn more about assembly. Anyways, my 2 cents. Am I a bit biased, perhaps <grin>. Beery

As long as it uses the FAT32 system and files on the SD card can be copied easily for a backup or file(s) added easily, that is all that really matters.

Great. When I took a second look at the board, that jumped out at me a bit. I wasn't too sure with the mini (?) SD card connector placement if it would be accessible external from an enclosure or not. I don't know if it has been explained earlier in the thread or not, but I am always backing up my SD cards in my DREMS for the HFDC especially when I am coding to avoid the risk of losing some code. Those images can be read by TIDIR as well. The TIPI files I can back up through a Windows shared folder. So, I am hoping either a Windows share can be created, or the files on the SD card for the SDD-99 can be read and at least backed up very easily. I have an SD card for a SCSI, and while I can back it up, it is basically making an image of the card due to the way SCSI partitions everything. I don't quite like this as much, but it is what it is. Beery

Going to make a quick suggestion here if this is something you have not already considered. With the final production board, have a hole in each corner so the SDD-99 can be secured in some kind of 3D printed enclosure. Not sure from the photo if that may require 90° LED's or maybe some of the external connectors to extend further out???? Myself, I hate seeing exposed electronics out from the side of a console. Between dust, potential cat hair, a drip from a drinking glass, etc., too much risk of damaging the board. I can just imagine one of my cats jumping from the desk with her back toenails scratching the board. Please note I am not suggesting you should also design the enclosure yourself unless you already were planning to do so. Just suggesting that if you were not going to offer the enclosure, that someone else with the 3D printing skills could design a board and offer it themselves and with mounting points, it makes the task that much easier. My 2 cents. Beery

I just too a quick look at the file with TIDIR with a hex view of the file. It's got embedded assembly code, however the program is relatively short. I'm guessing it wouldn't be too difficult to disassemble since it is so short. I have a suspicion it is just a matter of changing a byte from a >02 to >03, somewhere........ How quick is the disk copy process? Is it one of the < 30 second copiers, or something a bit longer. I ask, as there is a program, Rapid Copy for the TI-99/4A if memory serves me correct, that is pretty fast, and should have all kinds of configuration and setup options and should not require any editing. Now, if you had a Geneve, then there was HyperCopy which is THE FASTEST disk copier out there. Anyways, just throwing some options and a bit of info out there. I did take the time to run the program and code through DiskAssembler and the output is attached here if someone wants to look through it and potentially identify the byte(s) that may need to be changed. Hopefully, it would be just a byte change, though no promises. Beery BB1 BB2 BB3 BB4

I don't have an IDE card, and I don't know if there was ever a LOAD/SYS written/modified to load from that device. I've got a thought it may not be too difficult to do, but not having the original LOAD/SYS code for the Myarc HFDC, I can't say if a byte edit of the eprom code would allow a boot from the IDE. At this point, unless other code would be forthcoming (and their is that possibility) that is workable, any eprom update would be floppy, HRD, or TIPI only and not IDE, nor SCSI. MFM possibly. Beery

How about some kind of USB Wireless(?) multi-button joystick interface that uses the TIPI? USB mouse is already there, so it would probably not take too much effort.

Wow, 5 years ago, the Frys there in the NASA area was my goto place with what seemed like 30 or more employees on duty at any point in time. I assume that is the store you went too. Hate to see things so limited. I continue to check their website for weekly deals which for the last year or more, has not really had anything of interest to me. Beery

Going to throw a question out there. Is there anyone with a Geneve with only floppy storage capability, that would use (and buy if they do not already have it), a TIPI to load MDOS from the TIPI? At this point, just trying to ascertain interest. I am wading through some Geneve Eprom code and some LOAD/SYS code to try and be able to boot the Geneve from the TIPI. Neither the 0.98 Eprom nor the 1.00 eprom will permit booting from the TIPI, so if workable code can be written, it will require a Geneve boot eprom upgrade. As separate pieces, I already have eprom code loading load/sys from the TIPI on bootup, and separately have LOAD/SYS loading MDOS from an Editor/Assembler file. Working on the tweaks so that both pieces work together which is a bit more complex due to the way memory is mapped and used during the bootup cycle. Bootup times on the TIPI will be slower (~20 seconds) versus ramdisk, pfm, scsi, or pfm options. It will also be slower than a Jumpboot floppy disk. Once booted, the work Tim and I have been doing (mostly Tim's work), will give the TIPI file storage capability just like any other hard drive storage device. That part does not require any Geneve eprom upgrade. It's just to boot from TIPI would necessitate an eprom upgrade as neither 0.98 or 1.00 eprom anticipated the TIPI. Beery

Going to throw this out there if anyone has a need. The website frys.com if you do a search for Raspberry PI have them on clearance at $12.99 for a 3B+ with 1 MB ram. After you add it to your cart, you will then have to search the stores to find which one has them in stock. In the California stores, I found only one in stock. I did not check the other national stores. There was no description on the accessories like power supply, cables, fans, SD card, heatsinks, etc. that come with it, so it is likely it is a barebones device. The newer Raspberry PI 4's with 8 GB's ram with all the cables, cards, fans, etc runs between $120 to $150 on Amazon. Beery

Glad to hear another Geneve being resuscitated. Beery

I downloaded it, but never got it to work.