Jump to content

Photo

Nanopeb - "CALL UNMOUNT" not working


11 replies to this topic

#1 Zzalg_Repus OFFLINE  

Zzalg_Repus

    Space Invader

  • 27 posts
  • Location:Germany

Posted Sun Dec 2, 2018 3:22 PM

Hey guys!

 

I just encountered a strange bug with my Nanopeb - the command "CALL UNMOUNT(x)" does not work.

 

For me, it just MOUNTS the volume specified in the specified drive, so CALL UNMOUNT(1) will actually MOUNT Vol#1 in drive 1. CALL UNMOUNT(2) will mount Vol#2 in drive 2, CALL UNMOUNT(3) will mount Vol#3 in drive 3.

 

Can anybody reproduce this?

 

Or any advise? ;)

 

Thanks,

Frank

 



#2 OLD CS1 OFFLINE  

OLD CS1

    Technomancer

  • 5,787 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Sun Dec 2, 2018 3:32 PM

IIRC, this is intended behavior.  The default mounted volume per device.



#3 FDOS OFFLINE  

FDOS

    Chopper Commander

  • 232 posts

Posted Sun Dec 2, 2018 3:48 PM

It works as it's suppose to in all 3 of my NanoPEB systems (V1/V2/F18 V1), and use to work in my CF7A+ when it was functional.



#4 Zzalg_Repus OFFLINE  

Zzalg_Repus

    Space Invader

  • Topic Starter
  • 27 posts
  • Location:Germany

Posted Sun Dec 2, 2018 4:34 PM

I have an F18 V1.

 

And I don't think this is intentional. What does CATALOGUE actually show when a disk drive is unmounted?

 

Maybe this is an issue with the CF card? So far I haven't had any luck with CF cards, except for the one which came with my Nanopeb (at 128mb not *that* big). Has anyone have ever tried an SD to CF card adapter?


Edited by Zzalg_Repus, Sun Dec 2, 2018 5:00 PM.


#5 DavidC OFFLINE  

DavidC

    Star Raider

  • 66 posts

Posted Sun Dec 2, 2018 5:37 PM

This has been an ongoing topic of confusion with me.
From what I understand call unmount(1) will in fact mount dsk1,Volume 1

I guess it just defaults to that. I also have f18v1


I have a topic..."CF7+ question". It may be buried a few pages in, but there is some knowledge in the responses in that post.

I hope that helps, I'm still a noob.

Edited by DavidC, Sun Dec 2, 2018 5:41 PM.


#6 Stuart OFFLINE  

Stuart

    Dragonstomper

  • 809 posts
  • Location:Southampton, UK

Posted Sun Dec 2, 2018 5:56 PM

 

 

For me, it just MOUNTS the volume specified in the specified drive, so CALL UNMOUNT(1) will actually MOUNT Vol#1 in drive 1. CALL UNMOUNT(2) will mount Vol#2 in drive 2, CALL UNMOUNT(3) will mount Vol#3 in drive 3.

 

 

 

Correct - as per the CF7 documentation.


Edited by Stuart, Sun Dec 2, 2018 5:56 PM.


#7 R.Cade OFFLINE  

R.Cade

    Stargunner

  • 1,241 posts
  • Location:Augusta, Georgia, USA

Posted Sun Dec 2, 2018 6:09 PM

 

 

 

 

Correct - as per the CF7 documentation.

 

 

My NanoPEB does this.  

 

The documentation says:

CALL UNMOUNT(<drive number>) – un-mounts (removes) the disk drive and 
set the volume to the matching drive number. In other words, DSK3 will have 
VOL3 re-mounted. 
 
I take this to mean when you UNMOUNT a disk, it actually mounts the default VOL3.
 
FWIW, I find everything about disk and file management on the TI99/4a confusing, and this doesn't help.

Edited by R.Cade, Sun Dec 2, 2018 6:10 PM.


#8 DavidC OFFLINE  

DavidC

    Star Raider

  • 66 posts

Posted Sun Dec 2, 2018 6:18 PM

Yes. Call Unmount actually mounts the default volume (aka..disk) in that particular drive. Yes it is confusing. Yes, I'm just as confused about disk managment as you are.


If one of the brighter TI gurus could write a disk managment tutorial for dummies regarding the CF7/NanoPEB it would be well received..

Please?

Edited by DavidC, Sun Dec 2, 2018 6:22 PM.


#9 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,850 posts
  • Location:Silver Run, Maryland

Posted Sun Dec 2, 2018 9:32 PM

This really should not be confusing.  As several folks have already stated above, the nanoPEB and CF7 manuals describe CALL UNMOUNT(n), where n is 1, 2 or 3, as mounting the corresponding volume # to that disk #, which, of course, effectively unmounts whatever volume was previously associated with that disk #.  That is, CALL MOUNT(2,25) puts volume 25 “into” DSK2 and a later CALL UNMOUNT(2), puts volume 2 back “into” DSK2, unmounting volume 25 from DSK2 in the process.  [Edit:  Of course, if CALL UNMOUNT(2) is issued when DSK2 already has volume 2 mounted, nothing will appear to have happened.]

 

It makes little sense to me to expect the developer to complicate things by adding code to a DSR already strapped for space for the sole purpose of emulating an empty disk drive just so the user can pretend there is no disk there.  If that is somehow important, the closest scenario to that is to have volumes 1, 2 and 3 all be empty DSK images.  Actually, it might make better sense to have never implemented CALL UNMOUNT(n) in favor of CALL MOUNT(n,n), which is the real scenario, anyway.  It is a swap (1 step)—not out and in (2 steps) like real diskettes and real drives—but I digress...

 

...lee



#10 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,950 posts
  • Location:Portland, Oregon USA

Posted Mon Dec 3, 2018 11:20 AM

This is only a nanopeb/cf7 anomaly

TI disk and device usage is normally standardized and pretty straight forward. The only real quirk is that you can't do it catalog without a program or using a cartridge.

Remember to always CAPITALIZE device names

Sent from my LG-H872 using Tapatalk

#11 DavidC OFFLINE  

DavidC

    Star Raider

  • 66 posts

Posted Tue Dec 4, 2018 10:27 PM

I have figured it out, and it really is easy.

CALL MOUNT(1,5) loads disk number 5 into drive 1.

CALL UNMOUNT(1). Removes disk 5 from drive 1 and replaces it with disk 1, automatically. The drive is never empty. There is always a disk in it.

It is simple, but it can be confusing at first.

#12 Zzalg_Repus OFFLINE  

Zzalg_Repus

    Space Invader

  • Topic Starter
  • 27 posts
  • Location:Germany

Posted Fri Dec 7, 2018 5:23 PM

I just thought, going back to my original post, that leaving a disk in a drive other than DSK1 might cause problems loading certain programs. I seem to remember this from BITD with some A8/C64 games (C64 especially), where an active second, third ... drive would cause problems with copy protections, though I never experienced that myself on any machine.

 

(As an answer to myself: I *always* have "VOL1" in DSK3 - but then again there ARE some programs/games that won't run, but that's probably not because of having three active disk drives.)

 

Thanks, guys, for all your comprehensive replies! :thumbsup:


Edited by Zzalg_Repus, Fri Dec 7, 2018 5:24 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users