Loading CONFIG.SYS in Altirra

[TGB1718]

I have been trying (without success) to load CONFIG.SYS in Altirra, I had noticed some time ago that

CONFIG.SYS does not load even though I have set the paramaters correctly in the BIOS,

Boot Drive = D3:

CONFIG.SYS = D3:

 

The same CONFIG.SYS runs fine on real hardware, both Incognito and U1M+SIDE2, so looks like some sort of issue/settiing in Altirra.

 

for simplicity, I copied the CONFIG.SYS from CAR: and added lines to load the FATFS.SYS (file on the root of dD3:) and set a PATH

 

D3:TYPE CONFIG.SYS
DEVICE SPARTA OSRAM
DEVICE SIO
DEVICE ATARIDOS
DEVICE ULTIME
DEVICE JIFFY
DEVICE FATFS.SYS
SET PATH=D3:;D4:

 

I cannot access the FAT partition without FATFS.SYS, I can set the PATH with an AUTOEXEC.BAT.

 

 

Anyone else know how to get round this issue

[+Stephen]

I seem to recall having a similar issue - sorry I cannot provide any help, but watching the thread with interest.

[TGB1718]

Just thought I would ask, who would be the best person to flag this problem with ?

[+DrVenkman]

14 minutes ago, TGB1718 said:

Just thought I would ask, who would be the best person to flag this problem with ?

Either the author of Altirra (@phaeron) or the author of the Incognito/U1MB firmware you’re using (@flashjazzcat) would be the people to discuss this with.

[flashjazzcat]

On 4/23/2020 at 4:15 PM, TGB1718 said:

Anyone else know how to get round this issue

I don't know how to get around the issue as such, since I never encountered such an issue. I assume the hard disk partition is accessible on D3: (otherwise you would not have been able to write a file system to it or copy files to it), so your emulator settings should be correct. I assume the partition is formatted SDFS (a requirement for a partition hosting a valid CONFIG.SYS file).

 

What OS are you using (standard XL/XE)?

 

Note: '.SYS' is the default file extension for the 'DEVICE' statement, so may be omitted. Also, it is not necessary to point the 'Boot drive' setting at the partition containing CONFIG.SYS if one has already set the 'CONFIG.SYS' setting. 'Boot drive' is only used as the SDX boot device if 'CONFIG.SYS' is set to default. If the CONFIG.SYS setting is anything other than the default, SDX will use it and completely ignore 'Boot drive' (which is then used as the boot device only when SDX is not present). Ensure you're using U1MB firmware 3.10, since there was a regression regarding the 'fall back' properties of CONFIG.SYS/Boot drive in version 3.02.

 

[TGB1718]

In all respects other than it doesn't read CONFIG.SYS it works fine, I've used it to write and compile loads

of assembler programs, written again, lots of Basic programs, everything is just great.

List of Partitions:-

 

D3:LSDSK

D3:HDD 1.0.1.1       32MB 512bps
D3
D4:HDD 1.0.1.2       32MB 512bps
D4
D5:HDD 1.0.1.4     3398KB 512bps
[Untitled]
D9:HDD 1.0.1.3       32MB 512bps
 

D5: can be ignored, I only just created it to make sure creating a new partition wouldn't screw anything up.

 

 

I'm using standard OS XL/XE

 

I have upgraded to U1M 3.10

 

If I get time later, I will make an image of my SSD on the "real" 130XE and then restore it to a new VHD and attach that to Altirra and see what happens

[flashjazzcat]

9 minutes ago, TGB1718 said:

If I get time later, I will make an image of my SSD on the "real" 130XE and then restore it to a new VHD and attach that to Altirra and see what happens

If you can possibly ZIP down the VHD and send me a copy, I'll be happy to look at it here.

[flashjazzcat]

PS: Don't leave 'CAR:' out of the system path; it should usually be the first entry, followed by a semicolon and your additional entries. The 'DIR' command will not even work using your CONFIG.SYS.

 

Is the default drive 'C:' when the SDX prompt comes up?

[TGB1718]

I normally have CAR: as the first entry, was just trying things out in CONFIG.sys to see if I could get it working.

 

I set paths at the moment using AUTOEXEC.BAT

 

SET PATH=CAR:;D4:\BIN;D3:\;D3:\BAT\
SET MANPATH=D4:\MAN\

 

when testing CONFIG.SYS, I rename AUTOEXEC.BAT so I know it's not overriding the boot settings.

 

Yes, after boot, the prompt is D3:

[flashjazzcat]

36 minutes ago, TGB1718 said:

Yes, after boot, the prompt is D3:

OK: So the correct value is being placed in DUNIT at the correct time. Could it not be that a secondary issue is preventing FATFS.SYS from being located? Which is to say: can we firmly establish that CONFIG.SYS is being wholly ignored? The presence or absence of FATFS.SYS would seem at the moment to be the only indication of whether CONFIG.SYS has been located by DOS. Ditching AUTOEXEC.BAT for the moment and typing 'PATH' at DOS prompt immediately after booting would show us whether the 'PATH' line of CONFIG.SYS were processed or not.

[_The Doctor__]

Not that is should matter, but I had such an issue before as well. My work arounds were to include the paths as early as possible before my optional drivers, changed directories before some of them in the config or autoexec and furthermore included direct paths for certain drivers/items that continued to be stubborn. In that way, even if I moved stuff around... except my set in stone never changing goodies drive.... everything was found and worked as it should.

Edited May 9, 2020 by _The Doctor__

[TGB1718]

If I disable AUTOEXEC.BAT, PATH just shows CAR:

 

I have backed up my Incognito SD card which works as expected on my 800

 

I then created a new VHD and loaded the Incognito backup onto the VHD, loaded the VHD into Altirra

and CONFIG.SYS no longer loads, just as the original image.

 

The layout is a bit different, but I set U1M to the new boot drive which is D5: and Load CONFIG.SYS to Default

 

this is the CONFIG.SYS

FATFS.SYS loads on the 800, but not under Altirra.

and the path is only CAR:

So its not loading

 

USE BANKED
DEVICE SPARTA
DEVICE SIO
DEVICE ATARIDOS
DEVICE ULTIME
DEVICE FATFS.SYS
SET PATH=D5:\:;CAR:;D5:\BAT\;D5:>MAC65>

[TGB1718]

3 minutes ago, _The Doctor__ said:

My work arounds were to include the paths as early as possible before my optional drivers,

Any chance of a sample of what you did that worked ?

[flashjazzcat]

16 minutes ago, TGB1718 said:

Any chance of a sample of what you did that worked ?

It doesn't make any difference. What works on real hardware should work in the emulator.

 

Thanks for confirming that CONFIG.SYS is wholly ignored, anyway. It may be time to look at acceleration options in the emulator. I have everything turned off.

 

[_The Doctor__]

I'd like to replicate your situation, as would FJC it would seem.

a zip of your drive really is the best way forward.

In that way we can find out exactly what's got your individual issues brewing.

 

The problem is only happening in Altira correct? Always works on real hardware?

 

At the very least direct copies of your config sys and autoexec showing how you want your system set up (whether it is working or not) a zip of your setup is the only way to see where the flaw is. Sometimes it's the order in which they load or another conflict or something in the emulator, an odd rom, speed/timing.

 

*edit* looks like FJC is fully on the case... I'll sit back and see if I can mess mine up again in the mean time.

Edited May 9, 2020 by _The Doctor__

[TGB1718]

PM'd you both with a Zip of the SD card

[flashjazzcat]

41 minutes ago, TGB1718 said:

PM'd you both with a Zip of the SD card

Many thanks. As written in my response, I attached the image, changed 'CONFIG.SYS' to 'D5:' in the U1MB setup menu, and it simply worked.

 

So: the challenge now is to figure out what external (emulation, presumably) factor is causing the problem with your setup.

[flashjazzcat]

Oh well, that was easy.

I turned on 'Fast boot' and it immediately broke CONFIG.SYS processing.

[+Stephen]

34 minutes ago, flashjazzcat said:

Oh well, that was easy.

I turned on 'Fast boot' and it immediately broke CONFIG.SYS processing.

Well there we go.  That was also the cause of this same issue for me!

[TGB1718]

I have it fixed now, many thanks for your support on this issue, but...

 

when I de-selected Fast Boot, it didn't fix it for me, I had other selections, SIO Device Patches D patch disk and ? Burst

I de-selected these and it worked, now heres a funny thing, I was trying to see if anything else broke it, but with Fast Boot selected, mine works !!!

 

U1MB SIDE PBI BIOS v.3.10, dev. 0
Ultimate clock installed
FATFS v.0.86L

SpartaDOS X 4.49 8-04-2020
Copyright (C) 2020 by FTe & DLT

D5:PATH
D5:\:;CAR:;D5:\BAT\;D5:>MAC65>

 

This is mine now and it works

 

How odd, but you got it going for me, thanks again

 

[flashjazzcat]

Perhaps @phaeron can shed some light.

 

With Fastboot enabled, I see in the debugger (after monitoring SDX read requests on sector 1 of the boot volume) that high level emulation is stepping in and bypassing the PBI BIOS:

Pictured is a read operation with DUNIT = 3 (CONFIG.SYS volume). Enabling SIO Override Detection does not make a difference, so my advice is to ensure Fastboot is disabled.

 

Edited May 9, 2020 by flashjazzcat

[drac030]

27 minutes ago, TGB1718 said:

FATFS v.0.86L

A side note: wrong FATFS version, this one is for the SDX 4.47, long outdated. Use the 0.87L.

[_The Doctor__]

21 minutes ago, drac030 said:

A side note: wrong FATFS version, this one is for the SDX 4.47, long outdated. Use the 0.87L.

a link to where they can DIRECTLY grab the proper version is always a plus and / or adding an attachment..

[TGB1718]

25 minutes ago, drac030 said:

A side note: wrong FATFS version, this one is for the SDX 4.47, long outdated. Use the 0.87L.

thanks, will update it

[drac030]

17 minutes ago, _The Doctor__ said:

a link to where they can DIRECTLY grab the proper version is always a plus and / or adding an attachment..

Not a direct one, that is true, but the link to follow is in my signature: SpartaDOS X Upgrade Project, then (obviously) Download -> Release version -> Toolkit (as FATFS is a part of the SDX Toolkit). When flashing new SDX revision one should always check if the Toolkit does not by chance contain new revisions of the drivers, and if it does, update.

 

There were important internal changes in the SpartaDOS X:

 

1) in the transition from 4.46 to 4.47, with the new extended memory management scheme. At this point virtually ALL resident drivers which were taken from the Toolkit for 4.46 should be sent to the trashcan and replaced with the new revisions.

 

2) in the transition from 4.47 to 4.48, with the new PBI sector I/O protocol - this sent the FATFS 0.86L to the trashcan, and with 4.48 and later versions FATFS of version no earlier than 0.87L *must* be used.

 

So this is rather bad thing that 0.86L keeps circulating to this day.