Jump to content
tschak909

Upcoming feature - Mount-and-boot (mini)

Recommended Posts

I just checked in the code for mount-and-boot.

 

It adds a new option on the web admin, Boot Mode.

 

mount-and-boot-options.thumb.png.6a80d648efb75067b2f3157ec2b29e53.png

 

Default, it is set to CONFIG.

 

If you set it to Mount and Boot, it will boot into a tiny program which mounts the configured device slots, waits a few moments to see if you want to press SELECT, and if you don't, it boots.

 

If you do press select, it boots into CONFIG.

 

If the mounts fail, it will boot into CONFIG.

 

This has been checked into master and will be part of an upcoming build.

 

WIN_20210309_23_02_43_Pro.thumb.jpg.a6b1314076c156945effbef7480d4bee.jpg

 

WIN_20210309_23_03_11_Pro.thumb.jpg.02248e050cbb4ddbf440faeb687421f9.jpg

 

mount-and-boot-red.thumb.png.d596919dd6f52221e5dcd6051c6216d7.png

 

And of course, the code is here:

https://github.com/FujiNetWIFI/fujinet-mount-and-boot

 

To support this, code to set the boot mode has been added, and a new SIO command ($D6) can set the boot mode from daux1:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/SIO-Command-$D7-Set-Boot-Mode

 

-Thom

  • Like 7

Share this post


Link to post
Share on other sites

Nice 🙂

Random idea, some images requires OPTION button pressed at boot. Small enhancement would be to allow OPTION to start booting immediately without a need to wait with OPTION held down.

It can work like this: detect OPTION is being pressed, write some message, wait short time (to allow user to release OPT in case BASIC must stay enabled) and cold start.

What do you think?

 

 

Share this post


Link to post
Share on other sites

I don't like that idea too much, makes things more of a balancing act. it's only a few seconds. I deliberately try to keep things simple.

 

-Thom

 

Share this post


Link to post
Share on other sites
Posted (edited)

Is there a reason for the long delay? other than we expect a person to pour tea and add sugar lumps before deciding what to do? smack a key and skip it is a standard convention. Does it need time to make connections or something? To continue with other thoughts though...

 

I don't understand what the beef is with pressing a button on the fujinet to call the config up. It's the convention for just about anything for ages.

press the config button on the device, hit reset the Atari loads the config screen...

just because you allow that doesn't mean you can't use DOS to load the config etc

or using the new call, or all of the other methods that would still be there... you have so many more ways to get there already and they are good!

 

Let's say I have my BBS up, and there is a power cycle... I am half a state away...

the old bbs would just come back up when power restored...

as Fujinet sits right now... this doesn't happen... and won't...

I want it back up as fast as possible. Don't want to miss a scheduled event, network transfer for the day, or a caller if possible.

 

Let's say I have my daily driver set up...and I turn it on cold, I shouldn't have to see any of this stuff...

Fujinet should just do it's wifi thing and mount all of the slots the way I have them...

any DOS or whatever I am using should simply see the drives... if I need the other drivers and functions,  they just do autoruns/batches/whatever and load in as usual.

 

Why MUST a boot config run on the Atari at each full power up? I am missing it, other than perhaps waiting for slot to connect to servers, what else could be in need of the time.

I want to set up the drives and forget about it. Just walk up and turn on the Atari and go. If I want to change something, can't we do it in all the great ways you have already made possible?

 

I do understand that a tiny Boot strap might be needed for some new higher than before sio speed protocols, however that isn't fujinet as of yet afaik, and again that could be a config choice as well. Hell have Sam tell us how to get to config if you want :)    Fujinet can talk, it doesn't always need the screen, so certain things that do weird screen crap wouldn't be an issue either.

 

Keep it all just make it a choice in config, then everyone can tailor it to make themselves happy. You've done the work and none of it should go to waste... that's for sure. I hope some of this will help make things the best they can be...

 

I am waiting for the next revision board to propagate as I am willing to buy another #fujinet and give it another go.

 

A special thanks to APC for his work and thoughts as well.

Edited by _The Doctor__

Share this post


Link to post
Share on other sites
2 minutes ago, _The Doctor__ said:

Is there a reason for the long delay? other than we expect a person to pour tea and add sugar lumps before deciding what to do? smack a key and skip it is a standard convention. To continue with other thoughts though...

 

I don't understand what the beef is with pressing a button on the fujinet to call the config up. It's the convention for just about anything for ages.

press the config button on the device, hit reset the Atari loads the config screen...

just because you allow that doesn't mean you can't use DOS to load the config etc

or using the new call, or all of the other methods that would still be there... you have so many more ways to get there already and they are good!

 

Let's say I have my BBS up, and there is a power cycle... I am half a state away...

the old bbs would just come back up when power restored...

as Fujinet sits right now... this doesn't happen... and won't...

I want it back up as fast as possible. Don't want to miss a scheduled event, network transfer for the day, or a caller if possible.

 

Let's say I have my daily driver set up...and I turn it on cold, I shouldn't have to see any of this stuff...

Fujinet should just do it's wifi thing and mount all of the slots the way I have them...

any DOS or whatever I am using should simply see the drives... if I need the other drivers and functions,  they just do autoruns/batches/whatever and load in as usual.

 

I am missing something in my understanding at this point. Why MUST a boot config run on the Atari at each full power up?

I want to set up the drives and forget about it. Just walk up and turn on the Atari and go. If I want to change something, can't we do it in all the great ways you have already made possible?

 

I do understand that a tiny Boot strap might be needed for some new higher than before sio speed protocols, however that isn't fujinet as of yet afaik, and again that could be a config choice as well. Hell have Sam tell us how to get to config if you want :)    Fujinet can talk, it doesn't always need the screen, so certain things that do weird screen crap wouldn't be an issue either.

 

Keep it all just make it a choice in config, then everyone can tailor it to make themselves happy. You've done the work and none of it should go to waste... that's for sure. I hope some of this will help make things the best they can be...

 

I am waiting for the next revision board to propagate as I am willing to buy another #fujinet and give it another go.

 

A special thanks to APC for his work and thoughts as well.

*deep-breath*

 

unpacking your replies is an exercise in frustration, sometimes.. your thoughts can be hard to follow. with that said...

 

With the mini-boot, once you've set up your mounts, if the fujinet is cold reset for some reason, it will boot into the mini boot, wait for the wifi network to connect (if it hasn't already), attempt the mount all, and subsequently give a moment to press SELECT to go into CONFIG.

 

THE REASON this is done:

 

* The network may not be ready yet, if you try to mount something before the network is ready, it will fail.

* Since some people power externally and some power via the SIO, there is no consistent guarantee that the network will be ready by the time the mini boot loads.

 

After mounting, it waits a few seconds to make sure if anybody presses SELECT, if that happens, then it will jump to CONFIG. SELECT is actually checked in two different places, when mount-and-boot starts, and after the mount-all.

 

I do not understand why people are so confused by this. I genuinely sat down, and worked all of this through on paper and in my head before I actually implemented it.

 

-Thom

 

 

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

you might want to refresh your browser, I had typed a great deal while you quoted the whole first post without my entire thoughts about it in the post yet...

Edited by _The Doctor__

Share this post


Link to post
Share on other sites
Posted (edited)

Hopefully you read my post again... since you and I typed and saved at the same time. 42 vs 42 min by the forum clock.

 

Part of the issue is that slot 1 might be a local SD card boot disk...

If it's an SD card boot there is no need for the multiple checks of what is mounted before that boot, since normal boot time should be much much longer than network mounts to do their thing. Might be an order of operations type thing.

So mount all local SD card images, and let them boot, then do the network checks and mounts etc...

 

If the new SIO speeder idea gets incorporated, that boot time might evaporate though... ;)

 

That might help, it takes a bit of time for fuji to come up already, so a second or 2 is about all anyone might really need of want of further delay.

 

This still re-enforces why external power was a great idea, and IMHO the better way to fly. A great deal of Atari's shipped with puny supplies when brand new during the Tramiel  tenure and more so towards the end. You've dealt with a number of issues that didn't need to exist as a result and I sympathize.

 

It's hard to feed different thoughts into something after that process is laid and out and enacted already. The papers make perfect sense to the individual who writes them, others not so much. :)

 

This is why there are long drawn out and edited replies saying sometimes the sames things in multiple different way.

 

So I think I see a squirrel, no ball, um that's shiny... off I go.

 

T D

Edited by _The Doctor__

Share this post


Link to post
Share on other sites
1 hour ago, _The Doctor__ said:

Is there a reason for the long delay? Does it need time to make connections or something?

Exactly this.

 

As Thom explained, the network may not be ready so we need to wait for it if you have a TNFS disk selected in a slot. How are you supposed to boot a disk on the internet if there is no internet connection? Perhaps we can refine the process more so that if a SD disk image is chosen, then don't wait for wifi. For now this is a start in the right direction.

  • Like 3

Share this post


Link to post
Share on other sites

Don't let nattering nabobs of negativity get you down over a whopping 5 second delay. Thom's approach makes perfect sense and should work for all or nearly all circumstances. 

 

Looking forward to the next public build to try out. :) 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

We have tightened up the delay, and I think it feels better now. SELECT also immediately mounts config and boots with no delay.

 

SELECT is checked in two places, on program start, and after the mount all.

 

The initial delay that MAY occur happens if the network isn't finished connecting yet.

 

There is a second and a half delay after the mount all literally for cases of "oops I forgot to press SELECT" (aka the senior moment double check... we're all getting up there, and losing an occasional marble of focus along the way..) ;) ... we'll keep refining it. The reason for the longer delay was to give the user a chance to read the screen.

 

-Thom

 

Edited by tschak909
  • Like 2

Share this post


Link to post
Share on other sites
7 minutes ago, tschak909 said:

@a8isa1 debug info please? I've been booting XEX stuff from Homesoft, all evening.

 

-Thom

 

sorry, unable to build the fujinet_flasher on this old system.   I update the firmware with esptool.py.

 

-SteveS

Share this post


Link to post
Share on other sites
Just now, a8isa1 said:

sorry, unable to build the fujinet_flasher on this old system.   I update the firmware with esptool.py.

 

-SteveS

I can..not...help you... if you don't provide debugging information.

 

@mozzwald is there a switch for esptool.py to engage a debug monitor ? 

 

-Thom

 

Share this post


Link to post
Share on other sites
1 minute ago, tschak909 said:

is there a switch for esptool.py to engage a debug monitor

nope, esptool.py is just for flashing the firmware. 

 

@a8isa1 can you use minicom (or some other serial terminal) to get debug output (baud 921600)? 

Share this post


Link to post
Share on other sites
1 hour ago, tschak909 said:

I can..not...help you... if you don't provide debugging information.

 

@mozzwald is there a switch for esptool.py to engage a debug monitor ? 

 

-Thom

 

Still having problems.   Many XEXes will no load from my local TNFS server.  No activity light on FujiNet.

 

I'm providing a debug trace of the game Galactic Chase. Captured with mincom terminal emulator

 

-SteveS

 


CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ACK!
disk STATUS
response: 0x00, 0xff, 0xe0
->SIO write 4 bytes
COMPLETE!

CF: 31 52 01 00 84
FujiNet CONFIG boot
disk sio_process()
ACK!
ATR READ
->SIO write 128 bytes
COMPLETE!

CF: 31 52 02 00 85
FujiNet CONFIG boot
disk sio_process()
ACK!
ATR READ
->SIO write 128 bytes
COMPLETE!

CF: 31 52 03 00 86
FujiNet CONFIG boot
disk sio_process()
ACK!
ATR READ
->SIO write 128 bytes
COMPLETE!

CF: 31 52 04 00 87
FujiNet CONFIG boot
disk sio_process()
ACK!
ATR READ
->SIO write 128 bytes
COMPLETE!

CF: 70 fa 00 00 6b
sioFuji::sio_process() called
ACK!
Fuji cmd: GET WIFI STATUS
->SIO write 1 bytes
COMPLETE!

CF: 70 d7 00 00 48
sioFuji::sio_process() called
ACK!
::mount {5} "192.168.1.188"
::mount_local Attempting mount of "192.168.1.188"
::mount_tnfs {5:0} "192.168.1.188"
Calling TNFS::begin
Resolving hostname "192.168.1.188"
Resolved to address 192.168.1.188
TNFS mount 192.168.1.188[192.168.1.188]:16384
TNFS mount successful. session: 0x23c6, version: 0x0102, min_retry: 1000ms
vfs_tnfs_register "/tnfs0x3fff9c98" @ 0x3fff9c98 = 0 "ESP_OK"
Selecting '/Galactic Chase (1981)(Spectrum)' from host #5 as r on D1:
fujiHost #5 opening file path "/Galactic Chase (1981)(Spectrum)"
TNFS open file: "/Galactic Chase (1981)(Spectrum)" (0x0001, 0x01b6)
File opened, handle ID: 0, size: 15898, pos: 0
::get_filesize
tnfs_lseek currpos=0, pos=0, typ=1
tnfs_lseek success, new pos=0, response pos=0
tnfs_lseek currpos=0, pos=0, typ=2
tnfs_lseek success, new pos=15898, response pos=15898
tnfs_lseek currpos=15898, pos=0, typ=0
tnfs_lseek success, new pos=0, response pos=0
disk MOUNT
ATR MOUNT
tnfs_lseek currpos=0, pos=0, typ=0
tnfs_lseek success, new pos=0, response pos=0
ATR header missing 'NICKATARI'
::mount {1} "fujinet.online"
::mount_local Attempting mount of "fujinet.online"
::mount_tnfs {1:0} "fujinet.online"
Calling TNFS::begin
Resolving hostname "fujinet.online"
Resolved to address 157.245.127.133
TNFS mount fujinet.online[157.245.127.133]:16384
TNFS mount successful. session: 0x9f99, version: 0x0102, min_retry: 1000ms
vfs_tnfs_register "/tnfs0x3fffa9e4" @ 0x3fffa9e4 = 0 "ESP_OK"
Selecting '/cassette/O_Rileys_Mine.cas' from host #1 as r on D8:
fujiHost #1 opening file path "/cassette/O_Rileys_Mine.cas"
TNFS open file: "/cassette/O_Rileys_Mine.cas" (0x0001, 0x01b6)
File opened, handle ID: 0, size: 11891, pos: 0
::get_filesize
tnfs_lseek currpos=0, pos=0, typ=1
tnfs_lseek success, new pos=0, response pos=0
tnfs_lseek currpos=0, pos=0, typ=2
tnfs_lseek success, new pos=11891, response pos=11891
tnfs_lseek currpos=11891, pos=0, typ=0
tnfs_lseek success, new pos=0, response pos=0
disk MOUNT
Cassette image filesize = 11891
tnfs_lseek currpos=0, pos=0, typ=0
tnfs_lseek success, new pos=0, response pos=0
FUJI File Found
COMPLETE!

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

 

Share this post


Link to post
Share on other sites
Posted (edited)
30 minutes ago, a8isa1 said:

Still having problems.   Many XEXes will no load from my local TNFS server.  No activity light on FujiNet.

 

I'm providing a debug trace of the game Galactic Chase. Captured with mincom terminal emulator

 

-SteveS

 


CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ignoring status command

CF: 31 53 00 00 84
FujiNet CONFIG boot
disk sio_process()
ACK!
disk STATUS
response: 0x00, 0xff, 0xe0
->SIO write 4 bytes
COMPLETE!

CF: 31 52 01 00 84
FujiNet CONFIG boot
disk sio_process()
ACK!
ATR READ
->SIO write 128 bytes
COMPLETE!

CF: 31 52 02 00 85
FujiNet CONFIG boot
disk sio_process()
ACK!
ATR READ
->SIO write 128 bytes
COMPLETE!

CF: 31 52 03 00 86
FujiNet CONFIG boot
disk sio_process()
ACK!
ATR READ
->SIO write 128 bytes
COMPLETE!

CF: 31 52 04 00 87
FujiNet CONFIG boot
disk sio_process()
ACK!
ATR READ
->SIO write 128 bytes
COMPLETE!

CF: 70 fa 00 00 6b
sioFuji::sio_process() called
ACK!
Fuji cmd: GET WIFI STATUS
->SIO write 1 bytes
COMPLETE!

CF: 70 d7 00 00 48
sioFuji::sio_process() called
ACK!
::mount {5} "192.168.1.188"
::mount_local Attempting mount of "192.168.1.188"
::mount_tnfs {5:0} "192.168.1.188"
Calling TNFS::begin
Resolving hostname "192.168.1.188"
Resolved to address 192.168.1.188
TNFS mount 192.168.1.188[192.168.1.188]:16384
TNFS mount successful. session: 0x23c6, version: 0x0102, min_retry: 1000ms
vfs_tnfs_register "/tnfs0x3fff9c98" @ 0x3fff9c98 = 0 "ESP_OK"
Selecting '/Galactic Chase (1981)(Spectrum)' from host #5 as r on D1:
fujiHost #5 opening file path "/Galactic Chase (1981)(Spectrum)"
TNFS open file: "/Galactic Chase (1981)(Spectrum)" (0x0001, 0x01b6)
File opened, handle ID: 0, size: 15898, pos: 0
::get_filesize
tnfs_lseek currpos=0, pos=0, typ=1
tnfs_lseek success, new pos=0, response pos=0
tnfs_lseek currpos=0, pos=0, typ=2
tnfs_lseek success, new pos=15898, response pos=15898
tnfs_lseek currpos=15898, pos=0, typ=0
tnfs_lseek success, new pos=0, response pos=0
disk MOUNT
ATR MOUNT
tnfs_lseek currpos=0, pos=0, typ=0
tnfs_lseek success, new pos=0, response pos=0
ATR header missing 'NICKATARI'
::mount {1} "fujinet.online"
::mount_local Attempting mount of "fujinet.online"
::mount_tnfs {1:0} "fujinet.online"
Calling TNFS::begin
Resolving hostname "fujinet.online"
Resolved to address 157.245.127.133
TNFS mount fujinet.online[157.245.127.133]:16384
TNFS mount successful. session: 0x9f99, version: 0x0102, min_retry: 1000ms
vfs_tnfs_register "/tnfs0x3fffa9e4" @ 0x3fffa9e4 = 0 "ESP_OK"
Selecting '/cassette/O_Rileys_Mine.cas' from host #1 as r on D8:
fujiHost #1 opening file path "/cassette/O_Rileys_Mine.cas"
TNFS open file: "/cassette/O_Rileys_Mine.cas" (0x0001, 0x01b6)
File opened, handle ID: 0, size: 11891, pos: 0
::get_filesize
tnfs_lseek currpos=0, pos=0, typ=1
tnfs_lseek success, new pos=0, response pos=0
tnfs_lseek currpos=0, pos=0, typ=2
tnfs_lseek success, new pos=11891, response pos=11891
tnfs_lseek currpos=11891, pos=0, typ=0
tnfs_lseek success, new pos=0, response pos=0
disk MOUNT
Cassette image filesize = 11891
tnfs_lseek currpos=0, pos=0, typ=0
tnfs_lseek success, new pos=0, response pos=0
FUJI File Found
COMPLETE!

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

CF: 31 53 00 00 84

 

Looks like the file you're trying to mount, "Galactic Chase" doesn't have an extender on it, so it's assuming it's an ATR.

 

Can I see your slot list?

 

image.thumb.png.60ab0ee66bc49e700188bc90c056281d.png

 

-Thom

 

 

Edited by tschak909

Share this post


Link to post
Share on other sites
8 hours ago, a8isa1 said:

I  can no longer boot XEX files after this update.

 

6 hours ago, tschak909 said:

Looks like the file you're trying to mount, "Galactic Chase" doesn't have an extender on it, so it's assuming it's an ATR.

@a8isa1 Was your XEX file (without the file extension) working before? If you can rename the file, to end with ".xex" (or ".com" or ".bin") will it work? The code is (I guess for long time) detecting the XEX based on above listed file extensions.

Share this post


Link to post
Share on other sites

Loading from other servers was working and in the end his XEX problem was cured by restarting the local TNFS server. Case closed.

Share this post


Link to post
Share on other sites

It was a double whammy, he had RESET TNFS and SOME files worked...

he soon found out that .xex was also REQUIRED, for them to work...

 

so after that he's left to renaming everything.

Share this post


Link to post
Share on other sites

Wait, where was this solved? The thread literally jump cuts to, "We fixed it, my bad."

 

-Thom

 

Share this post


Link to post
Share on other sites
Posted (edited)

There were two separate issues as far as I can tell.

 

1) A binary load file I hadn't used previously used on FujiNet didn't work then 3 more files also did not work

 

2) Something happened to my TNFS server and nothing was loading.   I did not realize this at the time and thought this was a continuation of the issue above.

 

Mozzwald suggested I restart the server.   The file that was queued was a binary file that did have an .XEX extension.  I thought issue #1 had been solved.

 

However, the next file I tried was Galactic Chase.   This did not load.   I queued up each of the files that hadn't loaded the first time and once again none of them would load.  I thought nothing had been resolved.

 

I kept trying.   A new file, perhaps Bosconian, then worked.   At this point I had learned how I can obtain the debug data which I did and passed it on to Thom.

 

I subsequently learned that binary load files need an extension that FujiNet firmware can parse.  'XEX' was mentioned.   I was not previously aware of this requirement but now I am.  Problem solved.

 

I've never needed to do this for any other disk emulation, disk emulation hardware, or Atari emulators but now I know it's needed for FujiNet.  

 

The collection from sourced my files from was originally derived from someone else's disk set.  None of the file names have extensions.  Not knowing I needed file extensions I simply copied the files to the TNFSD folder.  

 

-SteveS

Edited by a8isa1
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

many people have collections showing the full names of executables using 11 character. 8+3 so you're not going to be the only one a8isa1. So now they know. Wonder what will happen if you copy instalgu.ide as standalone on tnfs to the screen editor...

copy D1:instalgu.ide S:
copy Dx:instalgu.ide SCN:

or PRN: or E: for whatever DOS or in program convention you come up with...

other such scenarios, might by time to run through some permutations...

 

Good job tracking it all down none the less.

Edited by _The Doctor__

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...