meta A new language for the Atari

[Kaj de Vos]

Thanks, guys, I was wondering about the support of DOS'es. Does XDOS have subdirectories?

 

Lots of thanks for looking into this, @sanny. I just got the first working result on SpartaDOS 3.2d. I don't even know what went wrong before; my code is functionally equivalent to yours. I probably didn't hit a working combination of DOS'es, disks and emulators. Knowing that it should work made me resume testing.

 

By the way, CC65 doesn't #define PATH-MAX. Looking at the code in getcwd.s, I saw that it should be 256 and defined it myself.

 

https://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html

 

It would be nice if CC65 would provide this.

[Kaj de Vos]

Ah, when SpartaDOS is on a non-SpartaDOS disk, getcwd () returns an empty string, so that is not standards-compliant. It could return NULL, but more useful would be to return a root indicator. SpartaDOS (at least 3.2) can't change into a non-SpartaDOS folder, anyway.

 

It's tricky what root indicator to return. SpartaDOS would want >, but MyDOS may want :.

[sanny]

You can call  _getdefdev() to find the "default" device. Prepend this to the result of getcwd() to get a fully qualified path name.

[Kaj de Vos]

On MyDOS, getcwd () always returns an empty string. This is the confusing thing. It's indiscernable from not doing anything at all. According to the standard, some sort of root path is expected:

 

https://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html

[flashjazzcat]

3 minutes ago, Kaj de Vos said:

On MyDOS, getcwd () always returns an empty string.

MYDOS has no facility for returning the working directory via the CIO. There was some chit-chat on the forum years ago about implementing one, but given the shortcomings of the 'default directory' in the first place, it didn't seem worth the effort.

[Kaj de Vos]

I understand, but it's not about a particular operating system, but about the definition of the cross-platform getcwd () standard. It can have a meaningful default, and otherwise, it is required to return NULL and set errno.

[flashjazzcat]

Ah - OK. Got you.

 

[sanny]

9 hours ago, Kaj de Vos said:

By the way, CC65 doesn't #define PATH-MAX. Looking at the code in getcwd.s, I saw that it should be 256 and defined it myself.

 

Latest git version of CC65 provides PATH_MAX.

[Kaj de Vos]

Cool, thanks!

[+CharlieChaplin]

12 hours ago, Kaj de Vos said:

Thanks, guys, I was wondering about the support of DOS'es. Does XDOS have subdirectories?

 

Nope. XDOS =  no subdirs.

 

MyDOS supports both > and : for subdirs.

 

[Kaj de Vos]

Good info, thanks!

[Kaj de Vos]

I guess most of you saw my anniversary treat:

 

Here is the code:

https://language.meta.frl/programs/DOS/platforms/Atari/8-bit/where.list
https://language.meta.frl/programs/DOS/platforms/Atari/8-bit/where.labels
https://language.meta.frl/programs/DOS/platforms/Atari/8-bit/where.map

 

 

either command= first-of system/program/arguments [
    print/line  either command = "about" [
        {WHERE
Copyright (c) 2021 Kaj de Vos}
    ][
        either command = "version" [
            "0.3"
        ][
            either all [width= system/console/width  width < 80] [
                {Usage:
  where
    Show the current working folder.
  where <option>
Syntax:
  example
    A literal word, such as the name
    of an option.
  <option>
    A term to be filled in.
  <option 1>, <option 2>
    Alternative parameters. Choose
    one.
Options:
  help, --help, -h, -help, -?, /?, /h
    Show this help text.
  about
    Show program info.
  version
    Show program version.}
            ][
{Usage:
  where                   Show the current working folder.
  where <option>
Syntax:
  example                 A literal word, such as the name of an option.
  <option>                A term to be filled in.
  <option 1>, <option 2>  Alternative parameters. Choose one.
Options:
  help, --help, -h, -help, -?, /?, /h, /help
                          Show this help text.
  about                   Show program info.
  version                 Show program version.}
            ]
        ]
    ]

    -1  ; Return warning number for scripts, in case an option was not meant
][
    unless /. = here: where [as-file here]

    print/line to-local-file here

    0  ; Success
]

 

The program is basically a command-line wrapper around the WHERE method, and shows several techniques for interfacing with the host system.

 

WHERE is analogous to the what-dir function in REBOL. I'm trying to avoid ugly, confusing abbreviations (Dire? Direction? Directive? Director?). I think WHERE is simpler and actually more REBOLish. It requests the current working folder from the system and converts it to a universal format, so that further manipulations can be done independently from the host system's folder separators and such. In this universal format, a trailing slash denotes a folder, as opposed to a file name. as-file strips that off.

 

to-local-file converts the path back to host system format for display. Speaking for myself, there is tremendous satisfaction in having, after twenty years, a version of REBOL's to-local-file that supports not only Windows, but also all Atari DOS'es.

 

This is a bit roundabout for this simple program, but it is how programs are constructed from smaller parts that fit together.

 

REBOL uses the % prefix for literal file names. I use that for binary numbers, being compatible with classic assembly syntax, and I want a more common notation for file paths. This necessitates using multiple prefixes:

    /absolute-file

    ./relative-file

    ~/home-relative-file

The / prefix is quite overloaded in REBOL, so in practice, this will become a little more complex. To avoid a conflict with the infix operator for DIVIDE, the literal root folder is denoted as

    /.

 

The program gets several system properties from the SYSTEM hierarchy. This is an important part of how the language makes cross-platform programming easier.

 

system/console/width is used to adapt the output of the help option to the screen width, choosing either 40 or 80 columns. Error messages, too, but that is done internally in the language.

 

Program arguments come from system/program/arguments. All multi-element data is abstracted as a SERIES! class data type. As much as possible, the same accessor methods work on all SERIES! types. This is a substantial part of how the language makes programs and programming less complex.

 

REBOL can only abstract external data after it has copied it into its own data types. This is convenient but highly inefficient. The exception are REBOL PORT! types, but they require extensive handlers to be written, broadly similar to CIO handlers, and the SERIES! abstraction for PORT!s is incomplete. My language can abstract external data directly without conversion, with much less code required, yielding first-class data types in the language. This is key to the performance improvement and the ability to target small systems.

 

On operating systems that support returning a number back from a program that finishes executing, the program returns a status code. Typically, this works on Unix systems, but the number supported is small, typically a byte. The language does this automatically when the return value of the last expression in the program is an integral number. Are there any Atari DOS'es that support this?

[sanny]

Hmm. IDK. The CC65 runtime lib returns the return value in A after calling `main()`.

 

Could be that SpartaDOS is using it.

[flashjazzcat]

SDX native relocatable apps support return codes (well - they need not be relocatable, but they use a proprietary file structure and commonly are).

 

Edited June 21, 2021 by flashjazzcat

[Kaj de Vos]

Cool! I saw SDX is quite C-like internally. Probably didn't notice that yet in the eighties. ?

[flashjazzcat]

The nice thing about SDX programs (and I couldn't realise the pleasure of coding native SDX applications until about a decade ago) is that they may call the 'library', which is a collection of symbolically linked functions permanently in ROM or RAM. One may even implement dynamic linked libraries and other such niceties. Even printf is part of the library, so simple CLI applications can be extremely small.

[Kaj de Vos]

Yes, really nice. I miss the concept of a resident library and especially a memory manager in DOS. Do any languages other than assembly target this format? The batch processor doesn't compile, does it?

[flashjazzcat]

MADS and Fast Assembler provide the only means of writing native SDX applications, AFAIK. Fortunately, since the learning curve for 6502 assembly language is not too steep and since cross-development tools are now so lavish, this isn't really an insurmountable barrier to entry.

 

 

[Kaj de Vos]

There are two important parts needed to develop a new language backend: the target language and the runtime library. A native SDX backend using the SDX library would develop much faster than a generic Atari backend if the SDX library is more comprehensive than the Atari OS.

[Kaj de Vos]

To make development paths viable, I need to strictly split them up into incremental steps. It would be doable to use my language framework to produce a sort of macro-cross-assembler for SDX. It would be a good step towards an SDX backend for the entire language, but that would have to come later, because it's a lot more work. First, you would get a cross-assembler that produces SDX file format, then calls of the SDX library functions in the form of my high-level language, then relocatable versions and support for more custom SDX forms such as TSR's.

[Kaj de Vos]

EMPTY.XEX, now even emptier!

 

I have set up a proof-of-concept skeleton for a native Atari backend. Here is a new version of Empty:

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

 

Instead of 517 bytes in the version generated through CC65, it is now 7 bytes. The only code it contains is an RTS needed as entry point by old DOS'es.

 

The CC65 version is now here:

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

 

 

The integrated assembler will be fairly easy to implement in the native backend, but the full language will be a lot more work. I can't do that now, we will have to see when it fits in the schedule.

[ivop]

Do you have a specification of this new language for us to read? I am curious about the syntax.

Edited June 28, 2021 by ivop

[Kaj de Vos]

Writing documentation will be one of the largest tasks. I reviewed the REBOL documentation, but less than I thought is applicable. Here are some sections of the old REBOL 2 documentation that are most relevant:

 

Quick Tour

Math

Series

 

Reading more of the REBOL documentation can prepare you, but it's full of little things that will have a different twist. I don't veer from the REBOL specification lightly, but it's really becoming a language in its own right.

[Kaj de Vos]

The most Spartan program ever!

 

I made a version of the native backend that produces relocatable SpartaDOS X programs. Empty comes out at 8 bytes, containing no code at all:

 

https://language.meta.frl/examples/platforms/Atari/8-bit/SpartaDOS-X/EMPTY.COM

 

[Wrathchild]

So are there listings behind these?