Jump to content
  • entries
    36
  • comments
    18
  • views
    33,658

Reconstructing APX Extended Fig-FORTH (APX-20029)


tschak909

1,393 views

blog-0352814001329519584.pngI decided one afternoon a couple of days ago, to clear my head from work, and various other projects, to do something else.

 

I do this from time to time, but what to do? Meh, I'm a hacker. I'll find another hacking project to wipe my brain clean.

 

I had always found FORTH to be an elegant language, if a bit steep to entry; especially given FORTH's extreme emphasis on efficiency and the alignment of the language entirely to that end. It looks and feels literally like Yoda's brain.

 

Add these numbers together on the stack, I do. 4 4 + .. yes, that adds 4 and 4 together, and puts them on the stack. It doesn't do anything else, because I haven't told it to do anything else. It merely prints 'ok' .. letting me know i had done so.. Would I type a period '.', or had added a period to the statement, it would have printed the number 8.

 

Yeah... Odd. Especially if you come from one of the many languages espoused by ALGOL (C, Pascal, Fortran, BASIC, Python, Shell Script). But it does have many advantages:

 

Grammatically, the language itself is very simple, a line in forth is merely a set of words, terminated by a <RETURN>

 

What words? you can ask for a list by typing VLIST at the prompt.

 

Need more words? you can add more words using the colon : word. end it with a semicolon.

 

: HELLOWORLD ." HELLO WORLD! " CR ;

 

now I can just type HELLOWORLD and have it output:

 

HELLO WORLD
ok

 

Couple this, with a variety of words that can easily access the hardware below, coupled with an assembler which can be used to quickly jump into 6502 assembler at any point, and it becomes evident how powerful FORTH really is. I literally see it as an interpreted language with a speed approaching native assembler (which is possible because of the sheer simplicity of the interpreter, coupled with the fact that the stack is used as efficiently as possible.)

 

So I put up with a degree of ...awkwardness in my own head, trying to shift to its unique way of doing things.

 

But why this FIG-FORTH?

 

This particular FIG-FORTH is literally a transliteration of Bill Ragsdale's 6502 FIG FORTH environment, with the relevant patching to make it work with the ATARI editor console, and with the appropriate patching to make it also work with CIO calls to the disk. This particularly makes the disk one big scratch pad, divided into blocks (128 bytes each, corresponding to a sector), and 8 of these blocks, forming together to produce one SCREEN (1024 bytes, which, is set up as 16 lines of 64 characters each.

 

This FIG-FORTH provides two commands LOAD, and SAVE (and their corresponding cassette equivalents, CLOAD, and CSAVE), to load and save the FORTH environment appropriately. LOAD takes one parameter, the screen # to load, and feeds it into the FORTH interpreter, line by line, as if it had been typed in by hand, and the resulting definitions are now present. SAVE on the other hand, saves the ENTIRE FORTH environment, the interpreter, and its compiled definitions to disk, creating a bootable FORTH environment with all the words that are active at the time the SAVE took place, making this environment very nice for game development. (IMHO)

 

You may be wondering, does this APX Fig Forth provide graphics etc functions? It does, but in the end, I won't be using them. Why? Because FORTH provides direct access to the hardware below, coupled with an assembler, I'll be able to make my own words specific to what I need, so in the end, I have what I need.

 

So what's first?

 

In essence, the APX Fig-FORTH on the disk is all there, but a few of the screens are corrupted slightly, and they need to be fixed. Well, unfortunately, a couple of the affected screens are literally inside the vocabulary that comprise the EDITOR. so what do I need to do? I need to type in the code for the words that comprise the editor, so I can recreate the screens on the disk. Yes, it's a chicken and egg issue., But. as I have implied before, anything on a screen can be typed directly into FORTH, and this is how I will get the editor back so I can edit the screens.

 

I am using the dump of the screens that Carsten Strotmann (aka cas here on the forums) put here: http://atariwiki.strotmann.de/wiki/Wiki.jsp?page=Extended%20Atari%20FIG-Forth%20APX20029

 

You can see the results of this:

3 Comments


Recommended Comments

I agree that FORTH is an interesting language. It almost seems to demand a bottom-up coding style. (Although I'm not sure how valid the "fast as assembler" mantra is.)

 

The problem I have with Forth is the lack of standard complex library functions (i.e. stdio in C) which makes it difficult to understand another's program.

Link to comment

it CAN be as fast as assembler, particularly when the assembler is used to generate words. It does tend to show a bottom up coding style, however you can indeed flesh out general ideas of the program and evolve them over time.

 

It is this bottom up "play with it approach", which evolves the tool you need for the task at hand.

 

The lack of standard complex library functions isn't a bad thing. The bad thing in FORTH is when people do not properly abstract, making programs that are a mash of higher level and lower level words. Yes, it's legal, and FORTH will stay the hell out of the way. This is why Chuck Moore called traditional programming languages "Dampeners" and called FORTH an "amplifier" ... It is a direct reflection of the programmer's mind. If a programmer doesn't organize his thoughts, it will show up on the FORTH screens, for all to see.

 

Now, I will say that I spend lots of my time in many different other languages, than FORTH. I love them all. C, C++, Objective-C, Smalltalk, Ruby, PHP, Perl, Python, Assembler for 6502, Z80, x86, PPC, ARM...BASIC... They have their weaknesses and their strengths, but I find myself liking FORTH on 8-bit micros like the Atari 800. Why?

 

Because it's just the right balance of small, fast, and flexible. The interpreter clocks in at under 8K, and most applications once compiled only add a few K on top of that for the program code (not counting any data), and when I need really fast, I can make words that drop right into assembler.

 

So sure, no standard set of stdio routines, but I will try to make my programs readable, after all, that is entirely within my control. :)

 

-Thom

Link to comment

BTW, I hit the same issue as you recently with the corrupted Forth disk and started fixing it with hex editor rather than from within Forth, since that's way easier.

 

But the corruptions were almost all the same error, sectors padded with the last character instead of space, which made me think the problem was a bad DCM2ATR conversion. Sure enough, if you take the DCM images from https://www.atariarchives.org/APX/showinfo.php?cat=20029and convert them back to ATR's, the images are different and not corrupt.

 

I should do some further auditing of the APX disks from that site.

Link to comment
Guest
Add a comment...

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