meta A new language for the Atari

[Wrathchild]

was just the first ATR I had to hand with a DOS on it, run in Altirra, used the disk menu (ALT+D) to explore the disk image and drag dropped the test.xex to it, returning to emulation then use 'L' to load 

Edited March 12, 2021 by Wrathchild

[Kaj de Vos]

I'm loading from the H: device. Perhaps that makes trouble.

[Wrathchild]

shouldn't do, with FujiNet you would be able to load it from the internet, its just a file with a given binary format/layout.

 

How are you launching it, e.g. with my test it will print but quickly the DOS redraws the screen and you lose the message, so putting a key-get at the end would help there

[Kaj de Vos]

Yes, that's why I prefer SpartaDOS. I don't want to double the size of Hello World. ?

[dmsc]

Hi!

On 3/12/2021 at 7:15 PM, Kaj de Vos said:

Hello, mystery!

 

I have been setting up a download server for the project. Here is Hello World from above:

 

https://language.meta.frl/examples/platforms/Atari/8-bit/HELLO.XEX

 

I am building it up custom. The files are served to you by the language itself.

 

I have a question. This being computers, even Hello World is unreliable. I can run it on DOS 2.5 and on Atari800 with SpartaDOS 2.3. On Atari800 it crashes with MyDOS and SpartaDOS 1.1. (I did choose an elevated start address to support SpartaDOS 1.1.) On Altirra, both SpartaDOS 1.1 and 2.3 produce an error instead of loading it, but no crashes. On Altirra with MyDOS, no crash and no error, but the text doesn't seem to be output, although it's hard to tell with the redrawing of the DOS menu.

 

Does anyone here know what could cause these behaviours?

 

The source and generated code are dead simple:

print/line "Hello, world!"

000000r 1               S0001:

000000r 1  48 65 6C 6C  .byte $48,$65,$6C,$6C,$6F,$2C,$20,$77,$6F,$72,$6C,$64,$21,$00

000004r 1  6F 2C 20 77  

000008r 1  6F 72 6C 64  



000000r 1               

000000r 1  A9 rr        lda     #<(S0001)

000002r 1  A2 rr        ldx     #>(S0001)

000004r 1  4C rr rr      jmp     _puts

However, CC65 generates a lot of boilerplate code around this. It seems most likely to me that the problems are in there.

 

You are calling the "_puts" C function, so the linker will bring the support for all the C stdio functionality - adding a lot to your program. Basically, there is a mismatch between what the C standard library expects and what the Atari OS provides:

- The C standard library is built around file handles (integers) that are allocated on OPEN and released on CLOSE.

- The Atari OS uses IOCB, those are 8 blocks of memory that each hold one open file, and are fixed in memory.

- The C standard library expects 3 already opened handles: 0 as standard input, 1 as standard output, 2 as standard error.

- The Atari OS on load opens the IOCB #0 as program input/output.

 

So, there is code in the CC65 library to translate between handles to IOCB, and on start it creates the three standard handles all pointing to the IOCB#0. Also, there is conde in the library to check whenever a handle is closed if it is the last handle pointing to an IOCB to close it.

 

The good news is that you don't need to rely on the C library in your language - simply don't call nay C function! This is what FastBasic does, if has it's own library of functions for all the functionality needed.

 

On 3/12/2021 at 7:15 PM, Kaj de Vos said:

I am disappointed that this out-of-control complexity has found its way into Atari 8-bit. Eventually this will need to be solved with a native Atari backend, but for now, I need to develop the cross-platform C generator.

Your program works on all DOS versions that I tried, and on the Atari 800, 800XL and 130XE.

 

Attached there are a few ATR images with the tested DOSs, so you can try them.

 

Note that most DOS clear the screen after the program ends, so you don't see anything. If you use an 800XL with BASIC enabled (the default when you boot the real Atari computers), you will see the message above the READY prompt.

 

Have Fun!

 

sparta32.atr bwdos.atr mydos.atr dos25.atr

[danwinslow]

On 3/12/2021 at 4:15 PM, Kaj de Vos said:

I am disappointed that this out-of-control complexity has found its way into Atari 8-bit. Eventually this will need to be solved with a native Atari backend, but for now, I need to develop the cross-platform C generator.

No offense intended, but just because you don't understand what's happening does not mean there is 'out-of-control' complexity. CC65 has exactly the boilerplate it needs to generate in order to work correctly in all situations. Plus, as Wrathchild mentioned, when you use stdio.h functions you get stdio library pulled in. That is not unreasonable.

[Kaj de Vos]

Thanks for the extensive testing!

 

@dmsc, last week I happened to look into FastBasic. I'm amazed how you fit it into that space. My language will be a little bigger, I'm afraid.

 

I made some small progress, but the issues are still there. The H: device on Altirra seems to only work with DOS 2.5. Oddly, all the other DOSes can list directories, but trying to load a file gives error 146. That's strange and made me suspect my executable first, but at least now I know it's Altirra's problem. I'm running it under WINE, if that makes the difference.

 

Altirra for me also crash-loops in a weird way on the DOS 2.5 ATR with the embedded program, but I already had it working on straight DOS 2.5, so that's just a side mystery.

 

It's nice to know that my executable can run embedded in the MyDOS ATR, but like the DOS 2.5 ATR, it's not a straight DOS disk. I can't boot to DOS with it, so I still don't have the program tested with straight MyDOS.

 

On Atari800 there seems to be no problem with the H: device, so we're getting closer to the problem there. Like SpartaDOS 3.2, BW-DOS works. It's small and seems to be very clean. It seems that humble DOSes have a better chance of running the program, but that doesn't explain why SpartaDOS 1.1 crashes. It does that after printing the output, so it does work, but then goes haywire, apparently on program return.

 

I would have liked to document programs from my language as compatible with all DOSes and emulators, perhaps after renaming to *.COM for SpartaDOS, but as of now, SpartaDOS 1.1 is not compatible and MyDOS doesn't seem to work from the menu.

 

I am familiar with the Atari OS. Once I specialised in writing drivers for it, a series of self-relocating high-speed SIO handlers for multiple floppy drives, the XL/ST-link and SIO2PC; and a SpartaDOS compatible CIO handler, before BW-DOS existed. Later I wrote an Atari emulator, and patched the CIO ? handler to access the PC's files, like the H: handlers now, when only Xformer existed, before Atari800 and Altirra.

 

I am aware of the C library layer in CC65. I have been digging through it fulltime for the past nine months. My compiler does many optimisations to decrease the impact of the C library layer. In the Syllable operating system project, I dealt with C libraries and maintained the port of the GNU C library to Syllable, where most of the adaption was to run portable software on Syllable.

 

I understand that on 8-bit, I am linking in the C library statically. This is not all that CC65 does: it also adds an extensive loader that does system checks for compatibility. I did not get any messages from it.

 

One would think that this experience should be enough to get a one-line, one-call Hello World working without problems, or if not in any case to debug it easily, but it is not. I implemented Hello World on day one of the project, nine months ago, but getting it up to release quality is still hard. All that time I have been searching the documentation, the source code, the Internet and this forum for information. All in all I have already spent days investigating these issues. I still think the main problems must be in the CC65 system check loader, but I still don't know. I tried to disable it, but this is very complicated due to the CC65 configuration system, and doesn't seem to be fully possible. The listings that CC65 generates are not as clear as they could be, they give relocatable code and don't tell the eventual addresses, and they don't include the added code. The included disassembler doesn't seem to support the generated Atari format, even though CC65 originated on Atari. The source code hasn't given me any clue about incompatibilities so far. This all makes it impossible to follow the usual procedure of cutting a problem into smaller pieces.

 

CC65 is a typical Unix tool set. It has way too many options, it is unhelpful in how to use them, it has bad defaults and all that functionality is not focused on solving the most important problems. I feel both empowered and obstructed by it.

 

I understand that this is nothing compared to the complexity in C environments on modern systems, let alone in newer languages. But it is a far cry from the standard of user-friendliness and documentation that Atari had, and the elegance of something such as Action!, which still draws me to these systems after 37 years. In my book, this is unnecessary complexity, and the way these components conspire to send you into the wilderness, it's out of control.

 

Of course, as I said, the eventual solution to this is to circumvent the C library, and C, and CC65 and not use any of it. I am able and willing to do that for Atari, but I can't afford it now, and I will never be able to afford it for all the systems that C can target.

[dmsc]

Hi Kaj!

 

3 hours ago, Kaj de Vos said:

Thanks for the extensive testing!

 

@dmsc, last week I happened to look into FastBasic. I'm amazed how you fit it into that space. My language will be a little bigger, I'm afraid.

? 

 

[snip]

3 hours ago, Kaj de Vos said:

I would have liked to document programs from my language as compatible with all DOSes and emulators, perhaps after renaming to *.COM for SpartaDOS, but as of now, SpartaDOS 1.1 is not compatible and MyDOS doesn't seem to work from the menu.

I think that very old SpartaDOS versions had compatibility problems with standard executables, IIRC it sometimes jumps to the start again on program exit. Also, the problem with MyDOS could be load address, or that the menu overwrites your program output.

 

IMHO, I would not worry about DOS compatibility at an early stage, after all users most likely use SpartaDOS-X, BW-DOS, MyDOS or DOS-2.5, and for text programs SpartaDOS-X and BW-DOS would be the proffered ones.

 

3 hours ago, Kaj de Vos said:

CC65 is a typical Unix tool set. It has way too many options, it is unhelpful in how to use them, it has bad defaults and all that functionality is not focused on solving the most important problems. I feel both empowered and obstructed by it.

 

My development workflow when working with FastBasic is in a Linux console, all driven by makefiles and unit testing:

 

- I assemble with CA65, adding the "-g" option, this makes all labels (even local ones) available to the linker.

- I link with LD65, with the flags "-Ln myfile.lbl -vm -m myfile.map", this produces a map file with the memory usage and a labels file with the location of all the labels.

- I test the program in the command line with my mini simulator: https://github.com/dmsc/mini65-sim . This simulator supports "D:" and "E:" devices, mapping to host files and standard input and output, and supports tracing (with "-t" option) and profiling (with "-p" option). In both modes, it can read the labels file so it shows executed instructions with all labels.

 

This is a sample session:

 

With this setup, I can automatically run many test cases - calling the FastBasic compiler and running the resulting executables, comparing the output with the expected result to detect any bad compilation.

 

And for the FastBasic distribution I ship an ATR with BW-DOS, I also made a little tool to generate ATR files in SpartaDOS format, this way I can be sure that people that tries FastBasic will have a reproducible setup.

 

IMHO, another good option if you want to use the DOS2 / MyDOS disk format is XDOS, it is also command line so it is easy to run a program and see the output.

 

Have Fun!

 

 

[sanny]

 

16 hours ago, Kaj de Vos said:

I still think the main problems must be in the CC65 system check loader, but I still don't know. I tried to disable it, but this is very complicated due to the CC65 configuration system, and doesn't seem to be fully possible.

 

See https://cc65.github.io/doc/atari.html#ss11.6

I don't consider that "complicated".

 

Why do you think that your problems lie in the system check loader? What exaclty are the problems?

 

 

16 hours ago, Kaj de Vos said:

CC65 is a typical Unix tool set. It has way too many options, it is unhelpful in how to use them, it has bad defaults and all that functionality is not focused on solving the most important problems. I feel both empowered and obstructed by it.

 

Which defaults are you considering are "bad"?

 

 

16 hours ago, Kaj de Vos said:

 

I understand that this is nothing compared to the complexity in C environments on modern systems, let alone in newer languages. But it is a far cry from the standard of user-friendliness and documentation that Atari had, and the elegance of something such as Action!, which still draws me to these systems after 37 years. In my book, this is unnecessary complexity, and the way these components conspire to send you into the wilderness, it's out of control.

 

This sounds like ranting. You know the documentation at https://cc65.github.io/doc/ ?

The flexibility cc65 provides comes with some complexity.

 

16 hours ago, Kaj de Vos said:

 

Of course, as I said, the eventual solution to this is to circumvent the C library, and C, and CC65 and not use any of it. I am able and willing to do that for Atari, but I can't afford it now, and I will never be able to afford it for all the systems that C can target.

 

Still, where are your problems? The C library works for most (all?) other guys. If you find a bug there, just tell me.

 

regards,
chris

 

[danwinslow]

I think he is mostly just expressing generalized irritation at the rise of control complexity over the last 30 years, an opinion which I mostly share although not in relation to CC65, plus he's apparently not a fan of linux/unix. I'm guessing he was 'raised' on some narrower architectures that had a smaller complexity footprint than mine had. For instance, I had never heard of the language he's doing until now. Kaj, if you think CC65 is complicated, wait until you see things like git and docker/kubectl and java/maven, and the insanely complex world of modern web development, in which it's not only (imo) too complex but also shattered into a thousand competing fragments of teensy little intersecting FOSS utilities. (See, I can rant too!).

 

CC65's extra complication is because of it's target, which is namely all 6502 machines. That's a broad brush, and it needs the flexibility in order to cover the targets. The price of flexibility is always complexity. CC65 is what it needs to be, and is medium-well documented. You've got to learn the tool, or pick another one up. You have nostalgia for simple, self contained things like Action!, which are Atari native. So do I. CC65 is an external, unix-style ( although not GNU-based) toolchain to produce cross-compiled stuff, so you are really not back in the 8 bit world when using it. I had some irritation and some extra time spent using it at first, but then I realized that once you cobble together the bits and pieces and flags you need, then you're set and have a lot of power at your fingertips. Asking without deriding the toolset is probably a better approach to gathering the information.

 

Modern C systems are not any more complicated than they used to be, actually. The systems they target and run on certainly are, though. 

Edited March 22, 2021 by danwinslow

[Kaj de Vos]

Thanks for the help! I have reached some conclusions.

 

@dmsc, your mini emulator is really cool! It's exactly what I mean: it's very well integrated and hits the sweet spot for the purpose, between the simplistic mini emulators in CC65 and the complex Altirra and Atari800. I was thinking in similar directions for my own emulator.

 

Those who wonder what the problems are that I'm experiencing, or what my background and plans are, please read back in this thread, where I elaborated on all of those.

 

@danwinslow, I don't think I am deriding the tool set. I also said I feel empowered by it. I am trying to give balanced formulations of my opinions of what's good and what's bad, when asked. I just expressed disappointment at having trouble getting a simple Hello World example to work fully, then some people objected, so I explained my disappointment, then more people objected. People seem a bit defensive and dismissive about it. A problem cannot be solved before it is acknowledged.

 

One way to view my language is that it will make using CC65 much easier. So am I a fan of it, or not? I don't know.

 

Am I not a fan of Linux? It runs on all my devices, multiple at the same time on some of them. I develop the language on it. I am making a web framework on it in my language that runs the server for the project. I think Linux can be improved much, so I made my own Linux distro. So am I a fan of it? I don't know.

 

There's a lot more I want to say, but I will save it for some later time. I'm not sure it will help right now to explain myself further. I think it's better to wait until I can answer these discussions with code. There's plenty of code of mine to be found on the Internet, just not in my own language yet. I would like to get Hello World out the door, so we can get to the interesting stuff. The problems are real, so let's work through them.

 

Take this minimal C program:

void main (void) {}

No new language, no stdio, not even any content, just C and CC65. Compile it with the CC65 defaults:

cl65 -t atari -o EMPTY.COM empty.c

On SpartaDOS 1.1, the system-check segment will abort the program, warning that it loads too low into memory and would overwrite SpartaDOS. It needs to be compiled with a higher start address:

cl65 -t atari --start-addr 0x2100 -o EMPTY.COM empty.c

Now it crashes on SpartaDOS 1.1. This is after the program runs, Hello World shows.

 

Interestingly, @dmsc's screenshot earlier hints that this is not due to some old DOSes jumping to the start of the segment. It shows the C program's run vector pointing to the second byte. I used @vitoco's XEX Filter and a hex dump to confirm that the first byte is indeed an RTS. CC65 does this right, as I would expect.

 

The program also crashes on MyDOS, apparently only when run from the menu.

 

@sanny, I can remove the system-check segment now:

cl65 -t atari --start-addr 0x2100  -Wl -D__SYSTEM_CHECK__=1  -o EMPTY.COM empty.c

I don't know why this didn't work last year when I found that switch. What I remember is that the system-check segment became smaller, but was still there. Perhaps I had still changed the configuration file in earlier attempts, even though I tried to start clean every time. Perhaps the -Wl was not in the switch when I first found it; I had been wondering about the supported syntax for a while. Perhaps I misinterpreted the segments, as they were hard to see with the included disassembler, because it doesn't support Atari format. I also updated CC65 since then, I don't know if that effected it.

 

I have several versions of a size coding demo, and they're measured by their file size, so I have been trying to remove the system-check segment from the start. It took nine months, but I'm happy that it finally succeeded.

 

Now the program works on MyDOS from the menu, so this bug is in the CC65 system-check segment.

 

It still crashes on SpartaDOS 1.1. An empty program only needs an RTS, but CC65 still adds a page of extra code. So feature analysis could be better, and this bug must be in that code.

 

@phaeron, running the program from the H: device in Altirra only works with DOS 2.5. SpartaDOS and BW-DOS report error 146. MyDOS redraws the menu without running the program. I suspect it also gets the error 146, but fails to report it.

 

So the CC65 defaults don't work with MyDOS and SpartaDOS 1.1, and a few other old DOSes that use memory beyond $2000. I also need to force it to use the zero page, because otherwise it generates big and slow code that doesn't cut it when speed is critical. I am surprised that MyDOS isn't supported. It has always been a popular DOS, one of the advanced ones. Many people need it for the drives they own. Like @sanny, I assumed that everyone had been using CC65 for decades, so a simple example like this wouldn't be a problem. This is unacceptable to me, so from now on I will remove the system-check segment.

 

I've had my Empty test case from day one, but I thought a blank program would be a little too boring to publish. Turns out I was over ambitious to skip straight to Hello World. Here is Empty compiled by my language:

 

https://language.meta.frl/examples/platforms/Atari/8-bit/EMPTY.XEX

https://language.meta.frl/examples/platforms/Atari/8-bit/empty.map

https://language.meta.frl/examples/platforms/Atari/8-bit/empty.list

 

Now with Empty out the door, back to Hello World.

 

[dmsc]

Hi!

4 hours ago, Kaj de Vos said:

 

 

Take this minimal C program:

void main (void) {}

No new language, no stdio, not even any content, just C and CC65. Compile it with the CC65 defaults:

cl65 -t atari -o EMPTY.COM empty.c

On SpartaDOS 1.1, the system-check segment will abort the program, warning that it loads too low into memory and would overwrite SpartaDOS. It needs to be compiled with a higher start address:

cl65 -t atari --start-addr 0x2100 -o EMPTY.COM empty.c

Now it crashes on SpartaDOS 1.1. This is after the program runs, Hello World shows.

Something should be bad with your setup, as here basic programs work ok, using current CC65.

 

See attached:

- SP11.ATR is an SpartaDOS 1.1 disk, with three programs: PROG0.COM, default compilation, PROG1.COM, start-addr at 0x2100 and PROG5.COM, start-addr at 0x2500:

 

All seems to work.

 

Now, the same buf with a MyDOS disk:

 

Not shown as the menu reloads over the message, but also works ok.

 

Have Fun!

 

    Daniel.

my.atr sp11.atr

[sanny]

10 hours ago, Kaj de Vos said:

So the CC65 defaults don't work with MyDOS and SpartaDOS 1.1, and a few other old DOSes that use memory beyond $2000

 

So you are referring to the default load address?

 

It used to be 0x2e00, and people were compiaining that it's too high. This was before "system check" and was deliberately set quite high that the program never ever crashes because it overwrote DOS.

 

I guess this is one of those cases where always somebody will complain regardless of what the setting is...

[Kaj de Vos]

The default load address, a MyDOS incompatibility in the system check segment, and a SpartaDOS 1.1 incompatibility in the startup/teardown code.

 

I think a default should be safe, and people who want it unsafe should change it themselves. This is not necessarily C's philosophy, but it is REBOL's philosophy, so my language will make that transition.

 

$2100 doesn't seem so bad to me to support several more DOSes. For what DOS was $2E00 chosen?

[danwinslow]

It was 'chosen' to support all of them. I don't know if there's a particular known DOS that drove the decision. It usually wastes a lot of memory, which is why people were annoyed with it as Sanny mentioned. It just is what it is, you have to adapt to the DOS situation. Either pick a DOS, or go high enough such that most DOSes are fine. Of course, any machine language program created by any means has the same issues, and some of those don't have defaults at all - you supply them in the source code or in the toolchain just as CC65 does.

 

I think a default should be safe, and people who want it unsafe should change it themselves

 

Yes, that seems to be a reasonable position. The point is, though, that at any time anyone could write a new dos that violates any default you set. The $2000 was seen as a reasonable compromise between memory usage and common dos's, and it is intended to be a starting point, not really a safe default.

[Kaj de Vos]

I know, memory management is problematic on all 8-bits. That's why I wrote the relocator for my handlers thirty years ago. I know a convention arose early that most application programs will start at $2000, so a DOS or handler that goes beyond that does so at its own peril. But at that time there were already a few DOSes that went slightly over it, which was no problem for BASIC, the most used "application program". So I always thought the convention is a bit off, and $2100 is better. SpartaDOS 1.1 is still my favourite DOS for testing, because it boots straight to the command line, fast. Most newer DOSes try to go as far under $2000 as possible.

 

Even better would be to write relocatable programs. That would also solve the memory differences between DOSes. But as far as I have seen, still only SpartaDOS X supports that.

[danwinslow]

27 minutes ago, Kaj de Vos said:

I know, memory management is problematic on all 8-bits. That's why I wrote the relocator for my handlers thirty years ago. I know a convention arose early that most application programs will start at $2000, so a DOS or handler that goes beyond that does so at its own peril. But at that time there were already a few DOSes that went slightly over it, which was no problem for BASIC, the most used "application program". So I always thought the convention is a bit off, and $2100 is better. SpartaDOS 1.1 is still my favourite DOS for testing, because it boots straight to the command line, fast. Most newer DOSes try to go as far under $2000 as possible.

 

Even better would be to write relocatable programs. That would also solve the memory differences between DOSes. But as far as I have seen, still only SpartaDOS X supports that.

Yes, I agree. I actually wound up interrogating the environment after load and using the space between my load point and the top of whatever dos as extra memory for some things, and also small relocatable bits of code. Bear in mind you can also use the RAM under the OS and extended memory too (hardware dependent though). Another popular target is a bankswitched cartridge, especially one that can be flashed such as the carts from Atarimax. https://www.8bitclassics.com/product/atarimax-maxflash-8mb-cartridge/

Don't know if that matches your use case though.

 

Sparta does natively support relocation, although as you know it's not terribly difficult to write your own using a table of addresses to be patched and your own loader.

Edited March 26, 2021 by danwinslow

[Kaj de Vos]

@dmsc, thanks again for testing!

 

More weirdness, and some verdicts.

 

I am still testing DOSes on Atari800 with the H: device, as this seemed to work. To level my environment with yours, I used Altirra's Disk Editor to import my programs to your ATR's. This sent Altirra into a fit when booting the SpartaDOS 1 image. It pops up a dialog box at a random place in the boot process, saying the system emulation ended due to a program error. This seems to be the same problem I had with the DOS 2.5 ATR that I got from @Wrathchild.

 

@phaeron, it turns out Altirra corrupted the SpartaDOS 1 image. This seems to have happened when I used the Disk Editor to rename *.XEX to *.COM for SpartaDOS. This does not explain how it happened to the DOS 2.5 ATR. Just importing to the SpartaDOS 1 and MyDOS ATR's, and renaming in SpartaDOS itself, works.

 

Now my programs work in SpartaDOS 1.1 and MyDOS! So the crashes are caused by the Atari800 H: device. This is really weird, because it works with all the other DOSes I tried. So both the Altirra and Atari800 H: devices are broken. But on Altirra it's fairly consistent due to an unimplemented CIO function that usually yields an error, while on Atari800 it only crashes SpartaDOS 1.1 and MyDOS in unexpected places. It's still possible that the code parts in CC65 that I identified trigger this, but the incompatibility is due to Atari800.

 

I think BW-DOS will become my new favourite DOS for testing now, to circumvent this and get the same performance as SpartaDOS 1.1. I added back the system-check segment and republished Empty (links above).

[Kaj de Vos]

Hmm, I didn't get an ATR from @Wrathchild. It was the DOS 2.5 one I got from @dmsc.

[Wrathchild]

@Kaj de VosHave you gauged how many people are using SD1.1? From what I recall the last, excluding SD-X, was around 3.2G in '94.

 

Also, the H: support in emulators doesn't use a DOS - it doesn't have TOC for example, so I think that's a red-herring too.

[Kaj de Vos]

As I stated several times, I use SpartaDOS 1.1 in my work flow. Why would I create a language and not look out for Number One? Also, anyone still using 8-bit is an archeologist. Why would archeologists destroy a historic site?

 

The H: device works on Altirra with DOS 2.5, and on Atari800 also with SpartaDOS 3.2 and BW-DOS, at least. So it's clear that this works and SpartaDOS 3.2 and BW-DOS could also work with Altirra. I don't see why MyDOS and SpartaDOS 1.1 could not also be made to work, and I don't see why that wouldn't be desirable. For one thing, it would have saved us many days. The biggest archeological site of all is Altirra. It has enormous functionality. Why should there be a taboo on adding this?

 

Anyway, these problems are resolved now. I got them out of the critical path, but I have to circumvent their traps in my work flow. In the process, bugs and limitations were discovered in Altirra and Atari800. Such things should be expected when exercising them with a broad new system such as a language.

 

From the land of herring eaters, I can tell you they should be red on the inside.

[ivop]

Keep in mind that H: devices are simulated ATR disk images. The emulator simulates the directory sectors, and tries to determine which file you are trying to load, and then produces 125+3 sectors that keep loading that file. That's DOS 2.5. MyDOS should be similar, but subdirectories make it more complicated. And larger sector links. SpartaDOS is a whole different beast. IIRC there were also changes made to the FS specification. The spartaDOS 1.1 file system is considered obsolete. The FS between 3.x and 4.x should be the same IIRC.

 

But opening four files from Basic, and start noting and pointing, reading and writing, and I'm pretty sure both H: device simulations will fail horribly even with DOS 2.5

Edited March 26, 2021 by ivop

[flashjazzcat]

50 minutes ago, ivop said:

Keep in mind that H: devices are simulated ATR disk images.

Surely 'H:' is a CIO device handler (hooked into the emulated machine). The virtual disk feature of Altirra works at the SIO (block IO) level, in the other hand, and bypasses the limitations of many DOSes with regard to 'H:'.

[ivop]

That's exactly what I meant. DOS simulation at sector/block level, i.e. SIO reads. Similar to how Aspeqt/Respeqt does the H: device. DOS 2.5 reads the VTOC and directory sectors through SIO. The H simulation creates sectors 360-368 on the fly.

 

[Kaj de Vos]

That sounds really contradictory. Disk format is read by the CIO D handler through SIO. How would H: work through CIO but simulate sectors for SIO? How does the D handler get inbetween?

Edited March 26, 2021 by Kaj de Vos
Still don't want D: replaced with smileys