Jump to content
dhe

Geneve Questions!

Recommended Posts

Okay. Just received my geneve and some stuff.

Now opened for the first time since 1985

IMG_20201031_142222388.jpg

IMG_20201031_142207195.jpg

IMG_20201031_142216456.jpg

IMG_20201031_142104306.jpg

IMG_20201031_142042191.jpg

IMG_20201031_142030500.jpg

IMG_20201031_142018925.jpg

IMG_20201031_141943331.jpg

IMG_20201031_143626670.jpg

IMG_20201031_143646266.jpg

IMG_20201031_143550016.jpg

IMG_20201031_143602104.jpg

Edited by GDMike
  • Like 3

Share this post


Link to post
Share on other sites
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. :) 

image.png.4a5238d7f3270e0e03b76f03d4be1066.pngarchive files, they open fine in tidir 

  • Thanks 1

Share this post


Link to post
Share on other sites
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  :) )

 

 

image.png.4004f43030a3059dc388e5260f0e2c08.png

  • Like 2

Share this post


Link to post
Share on other sites

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 by GDMike

Share this post


Link to post
Share on other sites
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). 

  • Like 2

Share this post


Link to post
Share on other sites

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 by mizapf
  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, InsaneMultitasker said:

All these goose and swan comments remind me of this little Easter Egg from early MDOS. heh

image.png.38ea1253a2ecd05e80318ff0232f86f2.png

 

This is oddly hurting my feelings... ;-)

  • Like 3

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites

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?

  • Sad 2

Share this post


Link to post
Share on other sites

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.

 

filezilla_setting.png

  • Like 2

Share this post


Link to post
Share on other sites
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.

 

filezilla_setting.png

 

ftp x

bin

hash

get

 

:)

also should probably uncheck treat files without extension as ascii.. filezilla kinda sucks, winscp is much better

 

Share this post


Link to post
Share on other sites
11 hours ago, OLD CS1 said:

 

 

How about "Untitled Goose OS"? :D

It is a lovely morning in the P-Box, and you are a horrible goose.

  • Haha 1

Share this post


Link to post
Share on other sites
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!

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
2 hours ago, InsaneMultitasker said:

or even a Geneve bumpersticker!   "Honk if you're ....  "?

 

Crazy as a goose for GENEVE laying a golden 9995..

  • Haha 1

Share this post


Link to post
Share on other sites
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 by GDMike

Share this post


Link to post
Share on other sites
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 /r

Gpl 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

 

 

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites
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?

  • Like 1

Share this post


Link to post
Share on other sites
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. 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...