GDMike Posted October 31, 2020 Share Posted October 31, 2020 (edited) Okay. Just received my geneve and some stuff. Now opened for the first time since 1985 Edited October 31, 2020 by GDMike 3 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 31, 2020 Share Posted October 31, 2020 5 hours ago, TheBF said: Does anybody know what these files are made with? The DOC files seem to be non ascii except for the file name. ??? Wonderful example of the problems archivists face with digital media. archive files, they open fine in tidir 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 31, 2020 Share Posted October 31, 2020 Cap check 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 31, 2020 Share Posted October 31, 2020 32 minutes ago, GDMike said: Okay. Just received my geneve and some stuff Couple of quick observations. This card has original regulators without heat sinks. The card may run for a while like this, but one or more regulators will eventually fail. Capacitors look to be original stock. The battery is most likely original (and dead). The extra 32K SRAM is not installed, meaning the latest MDOS / Geneve OS version it will load is v2.21. Video memory is stock 128K (no 64K upgrade). There is a trace correction on the back so this card was probably a second run or later. It doesn't look like the board run that had the brittle traces and through-holes. The monitor cable might be for a Magnavox or Philips RGB monitor, hard to be sure without checking the pinout. (Might be a good time to start a topic for your Geneve if you haven't already - depending on what you plan to do next ) 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 31, 2020 Share Posted October 31, 2020 (edited) I've got plenty of 32KSRAMs to place one on top of that other and wire it out. And the bus contacts need cleaning, and the clock battery needs a holder and replacement battery. Maybe I should move to: "Myarc cards for sale/repair tips" Edited October 31, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 31, 2020 Share Posted October 31, 2020 On 10/30/2020 at 11:32 AM, mizapf said: I cannot unpack these archives correctly, at least by my TIImageTool. Could be that the failure is on my side, of course. 4THDOC1A is broken, I successfully unarchived 4THDOC1A using an older MESS emulation, MDOS 6.50, and Archiver 4.0. The archive file was copied to a DS/DD (1440 sector) disk image using TI99Dir; I unpacked to the internal ramdisk thus I did not execute via rompage. (sorry, I am not able to try this on my real hardware or MAME at present). 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 31, 2020 Share Posted October 31, 2020 (edited) I'll try on my real Geneve. Sometimes I suspect that there are different versions of files by the same name - maybe changed by exports and imports. Edit: Tell you what - I cannot reproduce the problems today that I had yesterday. I downloaded the files from WHtech once more, and they differ. Starting at position 19338, a byte is missing in the downloaded file. At 33909, the next byte is dropped. This continues until 8 bytes are missing at the end, padded with zeros. I have no clue what happened to the file - a problem in the WHTech server, in the Firefox downloader? Or in my TIImageTool importer? So it does not make sense to look further. We should have more checksums in our files. (That's what I wanted to say - we ultimately trust the downloads, imports, and exports. If there are unknown glitches, we'll get into trouble some day.) Edited October 31, 2020 by mizapf 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 31, 2020 Share Posted October 31, 2020 Not that I know how to use itSent from my LM-V600 using Tapatalk 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 31, 2020 Share Posted October 31, 2020 4 hours ago, InsaneMultitasker said: All these goose and swan comments remind me of this little Easter Egg from early MDOS. heh This is oddly hurting my feelings... 3 Quote Link to comment Share on other sites More sharing options...
+9640News Posted October 31, 2020 Share Posted October 31, 2020 1 hour ago, mizapf said: I'll try on my real Geneve. Sometimes I suspect that there are different versions of files by the same name - maybe changed by exports and imports. Edit: Tell you what - I cannot reproduce the problems today that I had yesterday. I downloaded the files from WHtech once more, and they differ. Starting at position 19338, a byte is missing in the downloaded file. At 33909, the next byte is dropped. This continues until 8 bytes are missing at the end, padded with zeros. I have no clue what happened to the file - a problem in the WHTech server, in the Firefox downloader? Or in my TIImageTool importer? So it does not make sense to look further. We should have more checksums in our files. (That's what I wanted to say - we ultimately trust the downloads, imports, and exports. If there are unknown glitches, we'll get into trouble some day.) When I downloaded the file, it was with Microsoft Edge, the latest version via the html interface of the browser. Beery Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 31, 2020 Share Posted October 31, 2020 This is really interesting: $ od -An -tx1 -w1 -v 4thdoca.bin > doca.txt $ od -An -tx1 -w1 -v 4thdoca_broken.bin > docb.txt $ diff doca.txt docb.txt 19466d19465 < 0d 34037d34035 < 0d 107297d107294 < 0d 135306d135302 < 0d 146569d146564 < 0d 149305d149299 < 0d 186603d186596 < 0d 196223d196215 < 0d (first line: create a hexdump of the 4thdoca.bin file (which is 4THDOC1A of today) with single byte output per line; second: create a hexdump of 4thdocs_broken.bin (which is 4THDOC1A of yesterday); third: compare both hexdumps) The diff output indicates that the first file has some more bytes at the intervals xdx (line 19466-19466 etc.). So the result is that yesterday's version is missing some 0d bytes. Looking into the file reveals that these are the 0d bytes that are followed by 0a. So the download converted 0d-0a (DOS/Win) sequences to 0a (Unix) sequences. This is normally an indication of the wrong FTP mode ("ascii" vs. "binary"). I thought I downloaded the files with Firefox; I also worked with FileZilla that day. I retried it right now, and again, the files were transferred in ascii mode. It seems as if the "auto" mode of FileZilla took the wrong decision. When I set it to "binary", everything is OK. This is really unsettling. How many transfers have failed in the past? 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 1, 2020 Share Posted November 1, 2020 I think I finally got the answer I was looking for. Have a look at the checkboxes. This applies to everyone using FileZilla on every operating system: Make sure you set it to binary transfer! I found some comments on that in a forum. The reason for this setting is that people using FileZilla on Windows, pulling files like README from a FTP server, will have trouble reading them with notepad.exe when they were transferred in binary mode. Since most TIFILES files stored on WHTech do not have an extension, FileZilla will break them: Linux users get 0D deleted from 0D0A, while Windows users may find 0D inserted for every 0A in the file. 2 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 1, 2020 Share Posted November 1, 2020 12 minutes ago, mizapf said: I think I finally got the answer I was looking for. Have a look at the checkboxes. This applies to everyone using FileZilla on every operating system: Make sure you set it to binary transfer! I found some comments on that in a forum. The reason for this setting is that people using FileZilla on Windows, pulling files like README from a FTP server, will have trouble reading them with notepad.exe when they were transferred in binary mode. Since most TIFILES files stored on WHTech do not have an extension, FileZilla will break them: Linux users get 0D deleted from 0D0A, while Windows users may find 0D inserted for every 0A in the file. ftp x bin hash get also should probably uncheck treat files without extension as ascii.. filezilla kinda sucks, winscp is much better Quote Link to comment Share on other sites More sharing options...
JB Posted November 1, 2020 Share Posted November 1, 2020 11 hours ago, OLD CS1 said: How about "Untitled Goose OS"? It is a lovely morning in the P-Box, and you are a horrible goose. 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted November 1, 2020 Share Posted November 1, 2020 1 minute ago, JB said: It is a lovely morning in the P-Box, and you are a horrible goose. OOooo! And it should honk when it boots up! 1 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 1, 2020 Share Posted November 1, 2020 11 hours ago, arcadeshopper said: also should probably uncheck treat files without extension as ascii.. filezilla kinda sucks, winscp is much better Yes, that was in fact my major point (checkboxes), I just saw that my post looks as if I only commented on the radio buttons on the top. Quote Link to comment Share on other sites More sharing options...
GDMike Posted November 1, 2020 Share Posted November 1, 2020 COME GENEVE, you should be able to do MORE than HoNK.. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted November 1, 2020 Share Posted November 1, 2020 1 1 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted November 1, 2020 Share Posted November 1, 2020 6 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 1, 2020 Share Posted November 1, 2020 or even a Geneve bumpersticker! "Honk if you're .... "? Quote Link to comment Share on other sites More sharing options...
GDMike Posted November 1, 2020 Share Posted November 1, 2020 2 hours ago, InsaneMultitasker said: or even a Geneve bumpersticker! "Honk if you're .... "? Crazy as a goose for GENEVE laying a golden 9995.. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted November 2, 2020 Share Posted November 2, 2020 (edited) On 10/30/2020 at 5:06 PM, dhe said: SAMS memory access isn't supported by MDOS/Geneve. For memory expansion, you can add and additional 32K static chip (stacked) - if not already done. Heavily Modify a Myarc 512K Card. Or if you are luck enough to find one a Horizon Memex Card. And for Clarification, if I have maps made in tipi, are they not accessible to geneve? But if I run exec gpl they are? Edited November 2, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 2, 2020 Share Posted November 2, 2020 And for Clarification, if I have maps made in tipi, are they not accessible to geneve? But if I run exec gpl they are?Exec is one way with /rGpl is another with rompage The mdos dsr has no idea how to tipi.. rompage loads the card dsr Sent from my LM-V600 using Tapatalk 2 Quote Link to comment Share on other sites More sharing options...
Nick99 Posted November 2, 2020 Share Posted November 2, 2020 5 hours ago, arcadeshopper said: Exec is one way with /r Can you clarify Exec with /r, I never heard of that, how do I use it. Let´s say I will start YAPP, I normally use EXEC YAPP. Shall I put it EXEC YAPP /r and then I can load pictures from TIPI within YAPP? 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 2, 2020 Share Posted November 2, 2020 8 hours ago, Nick99 said: Can you clarify Exec with /r, I never heard of that, how do I use it. Let´s say I will start YAPP, I normally use EXEC YAPP. Shall I put it EXEC YAPP /r and then I can load pictures from TIPI within YAPP? Does the program (in your case, YAPP) work with EXEC without /r? Some programs require the BASIC GROMs or specific bytes in the TI ROM, and therefore must be run from the GPL program. Secondly, I implemented the "/r" option with the HFDC and SCSI in mind and IIRC it only does a power-up of the HFDC. This leads to some quirky behavior at times and is different from GPL where the TI ROM powers up all devices. Neither case should be an issue for TIPI since the Geneve EPROM performs a full-blown powerup of all devices on powerup. Edit: Only the later version of EXEC has the /r option so be sure you are using the right one. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.