Jump to content
IGNORED

Small Memory Footprint DOS


Recommended Posts

Coming soon LiteDOS 2.0 :-)

 

Full SD/DD-support and still only 2k in size.

Supports Turbo-Basic and its Compiler and Runtime.

The Command-line (DUP) has been completely rewritten and the format of the DIR-output.

LiteDOS: Memory above $1000 is free for use.

Remember, if users load drivers, it bumps this up.

post-6668-0-93966100-1548487672.png

Edited by mr-atari
  • Like 7
Link to comment
Share on other sites

LiteDOS is great and I intend to use it for future disk projects. There is just one issue which would raise when the program executable from this DOS would be used on other kind of media because of free RAM area otherwise not easily accessible without breaking other stuff.

So, I will need to make some note about this DOS in title screen.

 

Gury

Edited by Gury
Link to comment
Share on other sites

LiteDOS is great and I intend to use it for future disk projects. There is just one issue which would raise when the program executable from this DOS would be used on other kind of media because of free RAM area otherwise not easily accessible without breaking other stuff.

So, I will need to make some note about this DOS in title screen.

 

Gury

 

Perhaps the title screen code can check MEMLO and allow the user to quit when MEMLO is too high.

Link to comment
Share on other sites

Just remember that any software which takes advantage of the lower MEMLO by loading at a $1000 will be completely unusable by anyone who prefers another DOS. Loading below $1F00 or $2000 should be a last resort when all other avenues have been exhausted, particularly for applications. Of course the extra memory is useful for drivers and other optional components. But whether the title exits gracefully with a notice to the user or crashes on loading when running with another DOS, the end result will be the same (the user will go look for some other program which does work with their setup).

  • Like 1
Link to comment
Share on other sites

Just remember that any software which takes advantage of the lower MEMLO by loading at a $1000 will be completely unusable by anyone who prefers another DOS. Loading below $1F00 or $2000 should be a last resort when all other avenues have been exhausted, particularly for applications. Of course the extra memory is useful for drivers and other optional components. But whether the title exits gracefully with a notice to the user or crashes on loading when running with another DOS, the end result will be the same (the user will go look for some other program which does work with their setup).

This is a good point for utility applications where the used DOS matters.

On the other hand, It wouldn't matter much for a game shipped as a disk image or disk.

  • Like 1
Link to comment
Share on other sites

Yes: as I say - particularly applications, although many games are provided in ATR and XEX format, and the XEX should have a good reason for loading at an arbitrarily low address.

 

As for the choice of DOS: insisting on the use of a particular DOS is known to be an efficient method of limiting the user base.

  • Like 1
Link to comment
Share on other sites

Hi!

 

Coming soon LiteDOS 2.0 :-)

 

Full SD/DD-support and still only 2k in size.

Supports Turbo-Basic and its Compiler and Runtime.

 

The Command-line (DUP) has been completely rewritten and the format of the DIR-output.

 

LiteDOS: Memory above $1000 is free for use.

Remember, if users load drivers, it bumps this up.

I tried the download from your page, at http://www.mr-atari.com/Mr.Atari/LiteDOS/LiteDOS.zip

 

In Atari800 emulator: Loading turbo-basic did not work, (by doing "D" and then "L" in front of the file name), it crashes at startup.

 

In Altirra, even the disk directory (typing "D") did not work, some files are missing and "L" always produced "ERROR-021", see picture:

post-18634-0-15410000-1548535743.png

 

Command line was: Altirra TEST-LiteDOS2.atr /kernel:xl /ntsc

 

Any ideas what I'm doing wrong?

Link to comment
Share on other sites

Well, I have no idea.

I can not reproduce, so I have no clue.

Everything works here....

 

Error-21 and the screen-shot point out to corrupted data coming from IO.

On emulators, IO can be altered by acceleration or OS-patches.

 

Be sure to disable all other devices, acceleration and OS/IO-patches, stock OS.

Then try again.

 

Grtz,

Sijmen.

 

[EDIT]

Altirra-OS is not compatible I see now.

Edited by mr-atari
Link to comment
Share on other sites

It's not corrupted data. The problem is that LiteDOS is assuming A=0 on exit from SIOV at $0AE0, which is not guaranteed.

Yes, that is correct.

The data is not corrupted, the SIOV-return values are wrong.

 

"Atari/User Standards" makes it mandatory to end SIOV with A=0 and Y=1 or "Error" for best compatibility.

That is what I mend with "not compatible".

 

I simply used this "standard" too, to keep LiteDOS below 2k.

If I have room to spare in future, I can revert to "LDA #0" or "LDY #0", wasting bytes.

Instead of doing "DEY" or assuming A=0

 

Grtz,

Sijmen.

Link to comment
Share on other sites

Hi!

 

Well, I have no idea.

I can not reproduce, so I have no clue.

Everything works here....

I found the bug loading TurboBasic.

 

Problem is that TurboBasic implements its own binary loader for the RAM under ROM portions, and it assumes that IOCB#1 is opened by DOS to the binary file, so it continues reading using CIOV from the last file position.

 

But in LiteDOS you don't open IOCB#1, you simply "fake" it by doing:

 

 A=01 X=04 Y=10 S=F7 P=--*----C PC=09E0: 8E 5A 03  STX $035A   ;B1-ICAX1
 A=01 X=04 Y=10 S=F7 P=--*----C PC=09E3: 8D 51 03  STA $0351   ;B1-ICDNO
 A=01 X=04 Y=10 S=F7 P=--*----C PC=09E6: 88        DEY
 A=01 X=04 Y=0F S=F7 P=--*----C PC=09E7: 8C 50 03  STY $0350   ;B1-ICHID
This sets ICHID to 15, assuming DOS is device number 5. But if I enable H: device (that get's loaded *before* DOS), the device #5 is "H" and DOS is device #6.

So, the loader don't work if any device is loaded before LiteDOS.

 

Note that the device install routine, at PC=0823, correctly search for a free entry en HATAB, so in PC=082F the X register has the correct value to write at $350.

 

Regards!

  • Like 2
Link to comment
Share on other sites

Yes, that is correct.

The data is not corrupted, the SIOV-return values are wrong.

 

"Atari/User Standards" makes it mandatory to end SIOV with A=0 and Y=1 or "Error" for best compatibility.

That is what I mend with "not compatible".

 

I simply used this "standard" too, to keep LiteDOS below 2k.

If I have room to spare in future, I can revert to "LDA #0" or "LDY #0", wasting bytes.

Instead of doing "DEY" or assuming A=0

 

You're free to do whatever you want, but while the values of Y and N on exit from SIOV are generally recognized as standard, the value of A is not. More practically, none of the major emulators currently set A=0 in their SIO patch routines, so you are incurring a lot of compatibility problems for, in this case, zero bytes (TAY -> DEY). Only the direct calls to SIOV are the problem, the calls to DSKINV are fine.

  • Like 3
Link to comment
Share on other sites

Thanks for the feedback.

Time to redo some routines and update to 2.01

 

The device-ID $0F was on my todo list as potential bug.

The assumption of A=0 after SIOV, well, I borrowed that from other programs using it.

Better change that too, to be compatible to non-atari-standards, lol.

 

 

Beside that, what do you think about LiteDOS itself?

 

Grtz,

Sijmen.

  • Like 2
Link to comment
Share on other sites

Hi!

 

Thanks for the feedback.

Time to redo some routines and update to 2.01

 

The device-ID $0F was on my todo list as potential bug.

The assumption of A=0 after SIOV, well, I borrowed that from other programs using it.

Better change that too, to be compatible to non-atari-standards, lol.

 

 

Beside that, what do you think about LiteDOS itself?

 

Grtz,

Sijmen.

I think it is very useful!

 

I still don't look at the on-disk format, or in what it differs from DOS2 like formats that make it write-incompatible, do you have any info? I would like to write a C utility to generate disk images with included files. Perhaps the dir2atr tool could be modified to allow your format?

 

Only think I miss is a proper command line, perhaps as a loaded "DUP" like shell. IMHO, this would make loading command line programs easier and perhaps removing the limited shell support would make the installed portion smaller :P

 

Attached is a disk with a modified TurboBasicXL that loads at $1080 instead of $2080, giving you 4k extra RAM, and also has a few bugs fixed.

 

Regarding different DOS (with different MEMLO), I think that what we miss is a standard relocatable format, I imagine some binary format that would allow to be installed on any page, this would be compatible with whatever DOS the user likes.

tblite.atr

  • Like 2
Link to comment
Share on other sites

If it works on real hardware, it should work on an emulator... who's emulating who here?

with that being said, if it prevents it from working with a MIO etc... then it's a bug to fix....

both the software and emulation need a fix in that case...

 

I forget if it worked with the mio or black box and platoterm... but it must have as least worked with the MIO and a sio2pc in some limited fashion.

 

Mr. Atari, could you upload a couple litedos with other programs atr's so I could give it a re visit?

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

Here's the thing: even if all current emulators fix the A=0 issue, there is no time machine to go back and fix older ones. I'm of the opinion that it's unwise to write software that doesn't work on Atari800WinPLus 4.0 unless it either obviously can't run on it (e.g. physical cartridge) or there is sufficient and visible technical reason why it can't. Saving a couple of bytes isn't visible enough for users to think "the emulator isn't good enough" vs. "the software is broken."

 

As for the HATABS issue, that's definitely a problem on real hardware. Both the Black Box and the 816 OS will add R: and @: devices respectively before LiteDOS boots.

  • Like 3
Link to comment
Share on other sites

I have no love for many emulators, until lately that is, as your emulator just about checks all the boxes and I consider one of the best.

There is so much wrong with older emulation, do you think anyone is going to go back and fix them? Why would people be writing software to run on emulation that does not work, when it will work on current emulation and real machines?

Should we go back to all those old emulators where almost nothing feels or runs quite right? Current emulation is light years beyond what runs correctly on ancient no longer supports 7 years ago or longer emulations. You are far beyond what that emulator did. Should we all just scrap all the new emulation including yours and just use Atari800WinPlus 4.1, since it should only be written to run on that emulator, who needs anything else.

 

At one point I used litedos with the MIO without noticing an issue, so I ask Mr. Atari to send some litedos atr's with software to test the issue on both the MIO and Black Box... real hardware.

If it all works great if not then it needs to be fixed, seems like a logical way of doing it. If it breaks on an emulator, well that's something else entirely. If it breaks on both then is needs fixing. That seems logical enough.

 

chances are it really is a problem for the combination... and is indeed a bug... never know until we try!

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

I have no love for many emulators, until lately that is, as your emulator just about checks all the boxes and I consider one of the best.

There is so much wrong with older emulation, do you think anyone is going to go back and fix them? Why would people be writing software to run on emulation that does not work, when it will work on current emulation and real machines?

 

Well, because people still use older emulators. Atari800WinPlus 4.0 was the standard for a very long time, and until very recently there were not many good up-to-date options for macOS. I might have made a testing mistake on Atari800 4.0.0, though, looks like it might handle this. I have fixes pending for Altirra and AltirraOS, but those won't be out immediately.

 

I would also point out that the A=0 issue isn't necessarily emulator-only, that's just the case that we've confirmed. It is possible to also hit this on real hardware with unusual setups. 816-os doesn't unilaterally set A=0 on return but instead to the original value of CRITIC, which should also be 0 but isn't guaranteed. There are also a couple of cartridge-based disk emulators that work by patching JSR SIOV calls or soft-loading patched OSes into RAM which may also have issues with this.

 

It's not great to have to work around compatibility issues. I spent a full day rewriting some CTIA detection code recently because it failed on one emulator that had faulty GTIA collision behavior, and I've also had to work around the AtariMax cartridge loader not opening E: by default when running programs. You can argue about non-standard and non-Atari all day long, but in the end it comes down to how many people will be able to run your software on the environments they use and whether the workaround fundamentally changes the nature of your software or not (usually not).

  • Like 2
Link to comment
Share on other sites

Your an amazing person, I don't know what you run on... how you find time to do all the different projects you do and still have a life, and job is beyond me. I've watched you chew through some tough stuff and make short work of it. It seems you never give up once you commit to a path. sometimes it seems you know that about yourself, and as a result may filter out things that seem like it might not fit at the moment, and yet inevitably at some point you've made a note of it and it gets done anyway. As of this moment I think your emulator is the only one that is installed on all of my machines. only one machine has the best games pack on it with some other emulator. I do wonder if you sleep, or if we won't find the jokes on us and you're really AI specializing in emulation :)

 

I haven't checked recently, but I should check. Does the xwing center on the exhaust port to blow up the death star...it just might this time.

  • Like 2
Link to comment
Share on other sites

I have a 2.01 ready that fixes the issues.

Doing some final testing and then it will be uploaded to my homepage.

 

Thanks for the feedback.

 

dmsc:

The format is similar to ataridos, except I use clusters.

Only sector 360 is different and the VTOC length, data-structur on data-sectors are the same (125/253 bytes, sectorlink-h/l, data-bytes)

The bitmap is smaller and limited to 512 bit.

First byte if minus = LiteDOS mask #$7F gives you the (cluster size-1).

$83 = LiteDOS, clustersize 4

LiteDOS does not use file-ID-check, setting bit 4=1 of the file-status-byte

VTOC starts at 360 and goes up until 383, then wraps in that cluster (example to 256) and moves up again. Number of VTOC-sectors is the cluster-size

$83 meand VTOC 360-363, 3 sectors for names, equals 24 files.

$do $02 are the sectors on this disk, $bc $02 are the free sectors.

See screenshot.

 

The rest is the same as DOS 2

 

Grtz,

Sijmen

post-6668-0-51142300-1548747275.png

Edited by mr-atari
  • Like 2
Link to comment
Share on other sites

 

You can argue about non-standard and non-Atari all day long, but in the end it comes down to how many people will be able to run your software on the environments they use and whether the workaround fundamentally changes the nature of your software or not (usually not).

So true, so a fix is pending.

 

I am still learning on a dayly base, although I code for A8 now 35 years...

Writing a DOS from scratch and bumping in all kind of strange protocols is not easy and time consuming.

But then, coding is fun and I have fun, that is important.

 

Grtz,

Sijmen.

  • Like 7
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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