Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

568 Excellent

About BeeryMiller

  • Rank
  • Birthday 01/04/1964

Contact / Social Media

Profile Information

  • Gender
  • Location
    Campbellsburg, KY
  • Interests
    Powered Paragliding and scuba diving.

Recent Profile Visitors

5,604 profile views
  1. Not aware of a specific program yet written that would do as you ask. Myself, I can backup my 64 MB and 40 MB HD images on my HFDC in about 20 seconds, give or take. I'm using the DREM that has hard drive images stored on a SD card. Makes it pretty easy to backup those images on a Windows system. The price of a DREM is around $270. Not cheap, but for hard drive emulation using with the TI/Geneve by HFDC owners, I personally think that is the future. The DREM uses a 1/2 height drive bay. In principle, you could connect the DREM up as drive 2 and use your exisitng hard drive as drive 1, and copy files to it. If you had 2 MFM hard drives, you could move one of those 2 drives to drive #3 since it is read only, and copy from drive 1 to 2, as well as drive 3 to drive 2. The other option is to use Force Commander that Matt has developed, and to use the copy commands on it to copy to a TIPI setup. This assumes you are TI, not Geneve based. If Geneve based, the DREM would be the preferred route only because MDOS itself does not have MDOS file access to the TIPI and only TI programs could be run from the GPL "TI Mode" of the Geneve. Beery
  2. Tim provided some PETSCII code and thought I might try to link it to a dumb telnet terminal client I have. Someone had inquired about PETSCII BBS's back in some earlier threads, but if nobody is responding about what BBS's use PETSCII, then I guess emulation is not much of a concern...………. Beery
  3. Can someone give me a list of 2 or 3 PETSCII enabled BBS's out there? They need to be Telnet accessible. Thanks. Beery
  4. MyTerm for the TIPI YouTube Video
  5. Thought I would throw out on Tim's advice a repair job I did on my Geneve yesterday. Back about 2 weeks ago, the fan went out on my PEBox and I was unaware. While working on the Geneve, I started getting erratic behavior. Finally, I shut the PEBox down and for some reason, removed the cover. The side of the PEBox was almost burning hot, and the adjacent cards to the power supply were extremely hot. Those being the TIPI, Memex, and GenMod Geneve. I let everything cool down for the night with the cover removed. The next day, I swapped out the PEBox. Geneve swan would display, but no access was taking place on the HFDC. Swapped Geneve's around, things booted fine. In the other PEBox with the previously hot GenMod Geneve, I had one other card, a HFDC I knew was working. Geneve would not access the HFDC and would just sit there with no response. Pulled the HFDC, and the Geneve would transition saying it could not find System/Sys. I figured it was the bus chips. Discussed with Tim, and had to order some 74LS245's and 74LS244's. Replaced the 74LS245 and all was well. Fifty cent repair job. Beery
  6. Is the suggestion to use the TI keyboard on the RPI, or would the RPI have a separate keyboard? The A/D card could probably be used to create a software switch to open/close video outputs. One could probably use some kind of terminal emulation on the TI to feed the keyboard input as an output (7 bit?) on the A/D that would feed into the RPI possibly????
  7. OK, so I have a question. With the DREM, it has a CFG file that specifies the number of cylinders, sector size, sectors/cylinder, and a few other pieces of configuration information. The actual hard drive image, to my knowledge, is a sector by sector layout. Does the meta-information stored in the header of the CHD file for the gaps, ID marks, CRC, etc. change when sectors are rewritten? I've never fully grasped that level of hardware detail to know for sure, and even more unsure with MAME. If they don't, what would be the easiest process to do a copy of the DREM hard drive image onto a similar (say 40 MB) MAME CHD image? I've got the utilities to copy "bytes" from one image to any location of another image. Where I am going with this is that I have created a DREM image I am building source code files to make sure we always have them. Few people will have a DREM, but many more people would have access to MAME. Just wanting to make sure history is preserved, etc. Worse case, I suppose I could write a transfer program linking a Geneve to a Geneve/MAME emulation and read sector by sector from one image and write to the other with emulated hard drives configured the same. Beery
  8. Michael, I previously created a 128 MB image back over 15 years ago that has been upgraded to the later CHD formats. As such, the image is 128 MB's in size. So, I would presume the file does not grow over time. Besides, wouldn't the image during a format/verify fill in blank sector information? Beery
  9. Yeah, that was my general thought and was wondering if it could be used in that manner. Having a 512K ramdisk for < $10 would been an easy decision to make. When I asked it though, I questioned to myself, it seemed it would be without Extended Basic or E/A support the best I could tell. Everything would need to run from Basic unless I am missing something. I am wondering though if the memory mapping on the 512K unit would be the same as on the FinalGrom? Thus, if someone did not want to spend the money for the FinalGrom, they could go this route. And, if someone already had the FinalGrom, if the 512K could be simulated as a cartridge in the FinalGrom? Beery
  10. Just thinking out loud here. Could the DSR from the Horizon's Ramdisk be tweaked to use such a system? If so, is there any benefit to using a chip setup with more memory potential? Again, just thinking out loud. Another question. I know the FinalGrom has a lot of capabilities that have not been tapped yet. Is the Flash Cartridge setup you are proposing a subset of features on the Final Grom, or something more advanced? I am just trying to understand the details here. Beery
  11. While there isn't the physical limitation on capacity except by the size of the SD card on the PI, the DSR would have a 16 bit limitation on record numbers unless Matt expanded the record number count to something higher with an extended PAB. MDOS tried to do that, however, the last time I tried to use higher record numbers than a 16 bit number, it did not work on the Geneve. The MDOS XOP PAB has one extra byte with a maximum record count of either 24 bits if memory serves me correctly. I had a "database" of individual verses of the Bible that exceeded the 16 bit limitation and ended up having to break it down into multiple files using a different method of access. Highly unlikely this expanded feature was added by Matt as there would be almost no need/use of it for the TI. Beery
  12. In principle, I think one could write a backup program. One would read a SCSI drive sector by sector, then write a file, probably with 128 byte records, up to the maximum number of records for the file, then autoincrement the filename for subsequent files until the complete drive was written. Similar concept to what MDM5 did with the HFDC, though I think that was sector writes to the floppy versus record writes. MDM5 had issues when you tried to write to a bad sector. Downside here is what/how do you deal with bad sectors either on the read or write and how you flag them in the transfer process. Back years ago, Alan Beard wrote a program for the Geneve for MDOS that did an individual file read and archive to a path. That program was written in Fortran. I think the name may have been something like SFBACKUP. It embedded the filename/path/type up front in the beginning of the file for later restoration. We all know sector writes are not possible with the TIPI, however, a record based format should be doable. What I do not know is if the TIPI DSR has a restriction of 127 files at a file path, or how it would handle the situation if there were more than 127 files at a file path. Just some thoughts on how one might try to approach the issue with a TI system. Beery
  13. I should be able to get a demo video "soon". Got quite a few things on my plate and for the most part, been taking it a bit easy this past weekend. The PEBox power supply fan failing causing the whole PEBox to get !!!HOT!!! has caused the Memex Geneve to have an issue. Still need to chase down a few things to answer some of your questions regarding the tests with the unit. Beery
  14. OK Folks, I am uploading an archive with multiple programs in it for the TIPI for MDOS use on the Geneve. The file contains MyTerm modified to use the TIPI. It requires the use of the TIPI driver included with the package. One should also use IBMGRF ON in their AUTOEXEC file for some of the extended character definitions 128 and above. Second, there is another terminal program, TERM. Basically, it is a 1056 byte (5 sectors) terminal client using the Telnet protocol with the TIPI. It too, depends upon the TIPI driver that is included. Source code is included and shows how simple the TIPI can be used for programming on the MDOS side of things. Documentation is also included for both programs. MyTerm does include a phone directory as well as support for ANSI Color thanks to Tim along with file transfer capability. See the notes in the program. There are a few cosmetic issues still left to resolve in MyTerm, however the program I believe is pretty sound as is for general use. Generally, I believe non-color ANSI display is going to be extremely fast, perhaps faster than PORT. I haven't timed it yet. ANSI color should be about the same speed. File transfer speed with the TIPI will be at about 9600 baud equivalent speeds. This was due to not wanting to rewrite a bunch of Xmodem code for segmented blocks due to slow internet connections, slow serving BBS's, etc. As file transfers on the BBS side of things are limited, I focused my time on other things. Any feedback is appreciated. Beery TERM.ARK
  • Create New...