SDX on MiST?

[EdwardianDuck]

I was reading up on the MiST over lunch and was wondering if this remarkable device can run Spartados/X when the atari800 core is loaded? I've been unable to find anything online to confirm or deny this.

 

Has anybody tried this? If it does work, can a partition (disk image) of a few Mb be mounted and used (read/write)?

 

I don't own a MiST so I can't try it myself, or at least not yet. I'm asking because this might influence whether I order one or not.

 

Jeremy

[Panther]

I've been unable to get SDX to run on MiST with the latest 800 core. It doesn't accept the file as a cartridge, and the cart emulation in Turbo Freezer doesn't work.

Perhaps someone else has figured out a way?

[foft]

The turbo freezer does not include cart emulation since the cart emulation is already included. It's the same logic though.

 

What kind of cartridge is sdx?

[drac030]

There are several types of cartridges supported http://sdx.atari8.info/index.php?show=en_download_special

[Panther]

Okay, I took another attempt and found that the MaxFlash cartridge versions (both 1Mb and 8Mb) work.

[Panther]

The cartridge version of SDX that I'd expected to work was SDX447_sdx128.car, but it didn't. When trying to select it from the menu in MiST, it just returns to the menu without mounting it (Cart: NONE). While the SDX447_maxflash1.car image does load, I cannot access disk drives from it.

Edited May 5, 2016 by Panther

[EdwardianDuck]

My MiST arrived on Tuesday so I was able to briefly try this. As noted previously by Panther, the MaxFlash version boots, but trying to access a disk image mounted in drive 1 just gives Error 138 - Device Timeout. I get the same problem when trying to (re)format the disk or just get a directory listing.

 

Booting Atari DOS from the same disk (it has DOS 2.5 on it) worked as expected.

 

I don't really have any idea if the fact that the MaxFlash version boots on the MiST equates to "is suitable for running on it". I imagine that the SDX images which are not ~128Kb in size will be entirely unsuitable for the MiST.

 

Jeremy

[foft]

There aren't size restrictions. I guess it issues a less used sio command. Any idea which?

 

Format is not implemented I think. I guess I could zero the image if it helps.

[drac030]

The only "unusual" SIO command the SDX may use is "?" (Ultra Speed, get the high speed index). When it is not implemented, the communication should still go at 19200 bps.

 

It seems that it is a problem with POKEY implementation. The SDX serial routines do not use IRQ, the polling method is used instead. Perhaps not everything works well there in this respect.

 

By the way, the CONFIG.SYS file is being read using the OS SIO routines. So it should be possible to provide a disk which contains a CONFIG.SYS, that enables SDX to use the OS SIO instead of the default one.

 

Such disk must be in Sparta format, obviously.

[foft]

Perhaps there is a pokey problem but I believe a disk emulator problem is more likely, given I know the implementation of that is relatively poor:)

 

I should try it with aspeqt I guess.

[EdwardianDuck]

I finally got round to a little experimentation.

 

I created disk images (I tried 90Kb and 180Kb sizes) and formatted using SDX on an emulator. I then created a minimal CONFIG.SYS as below.

 

DEVICE SPARTA OSRAM

DEVICE SIO /A

 

On booting the MiST without the disk image mounted, I get a message about R-Time 8 not being present. This is what I expect when SDX is using the default CONFIG.SYS on the CAR: device.

 

On booting the MiST with the disk image mounted, I don't get the R-Time 8 message. This makes me think that SDX is reading CONFIG.SYS from the disk image.

 

Unfortunately I still get error 138 - Device timeout when I try any operation on the disk image (DIR for example).

 

I also tried /C instead of /A for the SIO driver, which made no difference.

 

Changing the speed setting in the MiST OSD for the drive emulation made no difference either.

 

Jeremy

Edited August 1, 2016 by EdwardianDuck

[drac030]

That is very unfortunate considering that the CONFIG.SYS is loaded from the disk using calls to OS SIOV ($e459) and that the SIO /A also redirects all the SIO communication to the same OS SIOV.

 

You can make sure that the CONFIG.SYS is really executed by adding the ECHO command at the end. Just append:

 

ECHO CONFIG LOADED

 

or something like that. Also make sure that the last line of the CONFIG.SYS file is ended with an EOL character, because otherwise it may get ignored.

[EdwardianDuck]

I've more or less given up on getting this to work, given foft's suggestion that the MiST core's disk emulation is relatively poor.

 

While it seemed that having config.sys on a disk image was having some effect, in the sense that the boot up messages were different, once I added ECHO statements it became clear that this was not being read / processed / or something.

 

However, for completeness I tried the following:

 

• I modified the default config.sys on the CAR: device to add /A to SIO.SYS.
• I tried each of the drive speed settings offered in the MiST OSD.

In each case a DIR command returned error 138 for the mounted disk image.

 

So I've convinced myself that it isn't going to work. I'll use something else.

 

Jeremy

[foft]

Yeah it looks like it expects command 0x4e to be implemented (read percom block) and my sd drive does not implement it.

 

It runs fine with aspeqt. I'm using the core on a different platform connected by an sio2pc.

 

Mark

Edited August 8, 2016 by foft

[drac030]

SDX does not strictly require the $4e to be implemented: if it is not, it will assume that the drive only does 128 bytes per sector, but it should still work in such a density.

 

But let me guess that the disk emulation probably does not react properly when fed with an unimplemented SIO command. From what EdwardianDuck writes, I infer that it just timeouts (error 138), while it should answer with the negative acknowledge ('N'), i.e. error 139.

[ijor]

I already got myself a MIST, and I am planning to implement VAPI support for the core, this should hopefully bring a more accurate SIO emulation for regular ATR images as well.

 

Not yet sure it will fit on all platforms, at least not without running code outside FPGA internal RAM.

 

 

[foft]

@Drac030: So I really need an 'else nak'. Sounds like I should also add the percom block to make dd work. I think it kept trying the command several times before timing out.

 

@Igor: That would be awesome. Let me know if you want an svn write account. Also if you have any questions.

[ijor]

Let me know if you want an svn write account. Also if you have any questions.

 

I might, thanks.

 

Well, the main problem is the very small ram amount available inside the FPGA. We might need to add core support for running code from external RAM ...