Jump to content
thej

"Modernizing" GraFORTH

Recommended Posts

Seeing all the new hardware that is available and soon to be released for teh Apple 2 got me thinking about how one would actualy utilize it.

Sure, some old programs are written to use RamFactor and other memory cards but is that all these new boards are for? Old software?

 

I think the collection of new hardware capabilities now available to the Apple 2 can open up some cool possibilities for the retro platform but new software will need to be developed in order to realize it.

 

I have been thinking about how this can come to be and I don't think Assemby or C will "inspire" the general population of retro-fans to jump in. However...

 

...I think GraFORTH might have a chance to inspire "new" programs that could actually utilize the existing and new hardware in a way that is more accessable that C or ASM. But...

 

...GraFORTH is old too.

 

It does have several pluses:

-Its an "Environment" !! Program and manage files

-Interactive development

-very helpful for new / inexperienced programmers

-FAST program execution (about half the speed of ASM program, much better than BASIC at 1/20th to 1/50th of ASM speed)

-Programs are Small

-...which leaves more RAM for Data (Graphics, Sound, etc)

-Because of the way FORTH works (words), High level constructs can be created and easily reused by the community

-Integrated 2D graphics capabilities

-Integrated Sound generation capabilities

-Integrated 3D graphics capabilities

- ...and manuals EXIST

 

 

And it has several negatives:

-Shackled to DOS 3.3

-140K disks do not allow for large programs, forces lots of disk swapping when developing large programs

-Designed for a 48K Apple 2+

-Integer only (TransFORTH, make by the same author, supports floating point but does not have graphics or sound support)

 

 

What would be required / wanted in a "Modernized" GraFORTH?

Essentials

-rebuild on top of a better "DOS" like NakedOS ro similar

-Support for large disk sizes / Flash volumes (already provided by NakedOS?)

-3.5" floppy support

-large memory support

 

Cool Possibilities

-Real time clock support

-Double High-res and Super-Hi res support

-Ad-Lib sound card support, GS sound support

-Network card support (ethernet, bluetooth, Zigbee, etc)

-16 bit version for 65816 2GS

 

 

Still reading? Great !!

I've posed this to get a conversation going in the community.

My Apple 2e and Apple 2C+ are collecting dust because I don't have time to learn enough ASM to do anything "Cool" with them. A modernized GraFORTH could offer a lot to the community and substantially reduce the effort / time required to jump into programming "Cool" stuff.

Unfortunately, I do not have the skills required to do such a modernization.

Do you ?!?

 

 

  • Like 1

Share this post


Link to post
Share on other sites

So your thinking :

 

a GraFORTH Re-Write that supports Addition Memory and the MockingBoard Sound Card ( Ad-Lib was an IBM PC Product on the i86 Architecture ) and larger Disk Drives and addition Hardware introduced under ProDOS.

 

OR

 

a GraFORTH Emulator that runs on Windows/Mac/Linux and supports Hi-Res Graphics, Stereo Sound other modern Hardware.

 

 

MarkO

Share this post


Link to post
Share on other sites

Yes! Exactly.... to both.

 

For non-Apple2 platforms, the base GraFORTH words could be ported to gforth or any other Forth for that matter. With that done, ANY GraFORTH program would work on those Forths as well.

 

Yes, definitely the MockingBoard. Not sure where my head was at !

 

ProDOS would work just dandy. I suggested NakedOS as it uses much less memory and is even faster than ProDOS with real floppies. Either one. Just not DOS 3.3 :-)

Share this post


Link to post
Share on other sites

Yes! Exactly.... to both.

OK.. There both good ideas... ;)

 

For non-Apple2 platforms, the base GraFORTH words could be ported to gforth or any other Forth for that matter. With that done, ANY GraFORTH program would work on those Forths as well.

Does gfourth have graphic or sound support?? Could it be used as the Basis of a new GraFOURTH??

 

Yes, definitely the MockingBoard. Not sure where my head was at !

30 plus years of Computer History will do that to you.. I started in JAN-1982 with the Apple ][+

 

ProDOS would work just dandy. I suggested NakedOS as it uses much less memory and is even faster than ProDOS with real floppies. Either one. Just not DOS 3.3 :-)

I actually favored a modified DOS 3.3, over ProDOS.

 

I used a Patch, that displayed the number of Free Sectors at the Top of the Catalog. ( I guess that DOS 3.1 did something like that, and it was removed in later versions. ), another Patch that would let you press ESC when the Catalog Paused to cancel reading anymore File Names and the Beagle Brothers ProntoDOS Patch..

 

I only mentioned ProDOS, because it has support for a Clock, and other Devices, while being extensible, such as Disk Sizes. I guess that SOS for the Apple ///, from which ProDOS was developed, has Device Drivers that load for different Devices..

 

I have never tried NakedOS.. How do they reduce the Memory Requirements?? Remove the INIT and FORMAT Code?? Shrink the Error Messages to Numbers like DavidDOS?? Other Magic??

 

MarkO

Share this post


Link to post
Share on other sites

No, to my knowledge gforth does not have graphics or sound support. It runs on UNIX/Linux/Mac OS X (command line).

 

 

As for NakedOS, it is a brand new DOS for the Apple 2. No Apple code. it supports floppies and that's it.

You can check it out here:

https://bitbucket.org/martin.haye/super-mon/wiki/Home

 

 

You can also see the GraFORTH demo on YouTube.

Edited by thej

Share this post


Link to post
Share on other sites

I used a Patch, that displayed the number of Free Sectors at the Top of the Catalog. ( I guess that DOS 3.1 did something like that, and it was removed in later versions. ), another Patch that would let you press ESC when the Catalog Paused to cancel reading anymore File Names and the Beagle Brothers ProntoDOS Patch..

No, DOS 3.1's catalog was the same as 3.3's.

 

I have never tried NakedOS.. How do they reduce the Memory Requirements?? Remove the INIT and FORMAT Code?? Shrink the Error Messages to Numbers like DavidDOS?? Other Magic??

They got rid of the BASIC interface.

  • Like 1

Share this post


Link to post
Share on other sites

I got so into watching this I pressed (return).

You can always download GraFORTH and Try it yourself...

 

I found it here, on a Virtual Apple Page:

http://www.virtualapple.org/apple2/GraFORTH.zip

http://www.virtualapple.org/docs/GraFORTH%20II%20Language%20Reference.pdf

 

 

 

I "had a borrowed copy", back in the day.. I thought it Interesting, but I was more interested in learning 6502 Assembler.

 

I found Paul Lutus to be a very interesting character... I can't locate his short Biography, but he did quite a few notable things, for NASA on the Space Shuttle, and then on the Apple ][.

 

MarkO

  • Like 1

Share this post


Link to post
Share on other sites

No, DOS 3.1's catalog was the same as 3.3's.

Hmm.. I can not locate the photo, but I saw a picture of a version of DOS, before 3.3, that had the Free Sectors added to the CATALOG. The Article I remember reading, back in about 1984 or 1985 was in a Magazine and Added Code to DOS 3.3, to display the Free Sectors. I recall that the article mentioned this was a previous feature that was removed. But then again, this was 30 years ago...

 

Here is an AppleWin Screen Shot of my Main Utility Disk:

gallery_34814_1116_16058.png

 

They got rid of the BASIC interface.

Yes, that would save a bit of space... I will need to try out NakedOS.

 

Thanks for the Tip....

 

MarkO

Share this post


Link to post
Share on other sites

That's one thing I liked about the Apple II, it was used at home by scientists involved with the space program. They knew which classic computer was the best!

 

And the Apple II had more down-to-the-chips bare metal than any other home computer did. Not on purpose, but because of when it was designed. Custom chips weren't really in the low-cost market yet. Everything was discrete logic except for the 6502.

  • Like 1

Share this post


Link to post
Share on other sites

That's one thing I liked about the Apple II, it was used at home by scientists involved with the space program. They knew which classic computer was the best!

The Commodore PET was a similar 6502 Machine, but started with a Calculator Keyboard, Limited Expandability, and a Disk System that was reasonably fast, but was way more complicated than the Apple's. The Apple ][, between Wozniak's 8 slots, and Open Architecture, and Jobs attractive Case and real Keyboard the Apple ][ really stood out...

 

When I was a teen, a friend of my dad's had a PET, with the Real Keyboard, and a couple Drives.. The Controllers were 19" x 12" Circuit boards.. That didn't include the Electronics inside the Drives.. Since I had taken my Apple ][ Drives apart before seeing the "competition's" drives, I was totally in awe of Wozniak Drive Design..

 

IIRC, I was snide enough, to mention that my drive controller was 3.5" x 5" in the Apple, and did most everything that this Motherboard size board did.....

 

And the Apple II had more down-to-the-chips bare metal than any other home computer did. Not on purpose, but because of when it was designed. Custom chips weren't really in the low-cost market yet. Everything was discrete logic except for the 6502.

The Commodore PET wasn't that special, but the C64, that is one computer that I am still envious over.. But NOT the Disk System!!!

 

Between the VIC II and the SID, I wish Apple would have made something similar between the ][e and the ][GS...

 

I have always wondered what an Apple ][ with the VIC II and a SID would be like...

 

I actually own a Commodore SX-64.. And I have a few C64's and C128's hanging around....

 

MarkO

Share this post


Link to post
Share on other sites

On the subject of new software platforms... have you seen PLASMA?

https://github.com/dschmenk/PLASMA/blob/master/doc/User%20Manual.md

I have been looking at it, wondering what it would look like on the 6809/6309 for the Radio-Shack Color Computer ( CoCo ). It should be possible to have Lawless-Ledgens running on the CoCo as well as the Apple ][/C64/Atari.

 

 

MarkO

Share this post


Link to post
Share on other sites

I have been reading the GraFORTH manual...

 

Did anyone know there is another companion product from Insoft, called TransFORTH?? Which supports Floating Point Math, and Arrays and other features for Science and Business purposes.

 

Looks like a Copy can be found on Asimov FTP Site:

ftp://ftp.apple.asimov.net/pub/apple_II/images/programming/forth/Transforth (Lutus 1981).dsk

ftp://ftp.apple.asimov.net/pub/apple_II/documentation/programming/forth/TransFORTH ][b Reference Manual.pdf

 

 

I would guess a Re-Write of these should include Both Personalities.

 

MarkO

Share this post


Link to post
Share on other sites

If I had some idea how to work the C64 hardware, I could try porting the Apple ][ firmware to it, and we could see for sure what an Apple ][ with a VIC II and SID would be like. xD?

  • Like 1

Share this post


Link to post
Share on other sites

If I had some idea how to work the C64 hardware, I could try porting the Apple ][ firmware to it, and we could see for sure what an Apple ][ with a VIC II and SID would be like. xD?

You need to start with one of these:

gallery_34814_1116_35430.jpg

 

Download a .txt version from here:

http://project64.c64.org/hw/c64prg10.zip

 

( Still looking for a Scanned PDF version... )

 

 

MarkO

Share this post


Link to post
Share on other sites

Man, I wish other computers were as easy to code for as the ][. x.x

The VIC20 and the C64 had lots of very complex chips in them. Commodore didn't seem to mind providing the Schematics for them, because if they were Cloned, like the Apple ][ was, the Processors 6502/6510, the VIC(-II)6560/6566 and SID 6581/6582 and IA/PIA/CIA 6520/6522/6526 would have to be Cloned too, or bought from Commodore.

 

MarkO

  • Like 1

Share this post


Link to post
Share on other sites

Well, I've been doing a LOT of reading and I have discovered a few things.

 

I originally listed several "possibilities" but I have realized that rewriting parts that use DOS will probably take me a long time. I am learning as I go so that will likely be the hardest stuff to do. So, last on the list.

As well, NakedOS only supports 5.25" disks so it looks like it will need to be ProDOS.

 

The GraFORTH documentation has a full list of all of its parts and where in memory they are placed (AWESOME!! I thought I would have to figure all that out myself !). However, it has a few configurations based on whether the Apple2 has a language card installed. GraFORTH uses the additional memory in the language card. This could get intricate (remember...learning as I go) as some of the other features I wanted to add also use the memory in the 80 column/language card.... like Double-Hi Res.

 

Found a couple great resources for DHGR.

One is here: http://apple2.boldt.ca/?page=til/tn.aiie.003

Had some difficulty following along with the instructions toward the end but it is a GREAT resource.

Has lots of memory maps explaining DHGR.

Another resource for DHGR is the book "Inside the Apple IIe" by Gary B. Little.

WOW !! What a great book !! If I'm going to be able to rewrite the DOS parts of GraFORTH, it's going to be this book that gets me there !!

 

So I'm hoping to start by simply adding new Forth words to GraFORTH.

Words for DHGR and other things that require memory accesses and calculations look like the easiest enhancements to start with. Things like 80 column display, real time clock support, MockingBoard support are within range (I will need to eBay a no-slot-clock). Maybe even RAM expansion boards (will need to learn about the various forms of bank-switching later )

 

Onward and upward !!

 

Hey!? Anyone trying out GraFORTH yet?

Edited by thej
  • Like 1

Share this post


Link to post
Share on other sites

Well, I've been doing a LOT of reading and I have discovered a few things.

 

I originally listed several "possibilities" but I have realized that rewriting parts that use DOS will probably take me a long time. I am learning as I go so that will likely be the hardest stuff to do. So, last on the list.

As well, NakedOS only supports 5.25" disks so it looks like it will need to be ProDOS.

Unless you are Reverse Engineering GraFORTH by Dissembling the Program, you don't need to Rewrite anything.

 

Look at ALL the features of GraFORTH, and write ( or Port ) a FORTH Interpreter to NakedOS or ProDOS. Add the Primitives that GraFORTH has, and Add the additional Primitives that you want.

 

The GraFORTH documentation has a full list of all of its parts and where in memory they are placed (AWESOME!! I thought I would have to figure all that out myself !). However, it has a few configurations based on whether the Apple2 has a language card installed. GraFORTH uses the additional memory in the language card. This could get intricate (remember...learning as I go) as some of the other features I wanted to add also use the memory in the 80 column/language card.... like Double-Hi Res.

A Memory Map will help a lot in understanding what GraFORTH encompass, and how it should work.

 

DOS 3.3 ( and older versions ) didn't use the RAM beyond 48K, ( the Alternate BASIC did, but you don't have to load it ), so having a GraFORTH editor that would load up there is helpful in getting the Maximum RAM usage of the lower 48K.

 

ProDOS requires the upper 16K, and Won't Run on a 48K system. So the Dual Editors would be fine on NakedOS, but not really necessary for ProDOS, unless you want to use some of the Memory in the additional 64K bank on the Standard 128K //e, or //c or IIgs in 8 bit mode. I have some Applied Engineering RAMWORKS III cards, which have up to 1MB on the basic card, and up to an additional 2MB on a Daughter Card. Being able to use some or all of that memory would be a large benefit.

 

Do you want to Support a 64K RAM System, from an Apple ][ on up?? Or is 128K Apple //e or //c going to be the minimum system???

 

Found a couple great resources for DHGR.

One is here: http://apple2.boldt.ca/?page=til/tn.aiie.003

Had some difficulty following along with the instructions toward the end but it is a GREAT resource.

Has lots of memory maps explaining DHGR.

Another resource for DHGR is the book "Inside the Apple IIe" by Gary B. Little.

WOW !! What a great book !! If I'm going to be able to rewrite the DOS parts of GraFORTH, it's going to be this book that gets me there !!

These are both a fantastic resource, there are other documents that are helpful as well... I will locate some additional links and post them..

 

So I'm hoping to start by simply adding new Forth words to GraFORTH.

Words for DHGR and other things that require memory accesses and calculations look like the easiest enhancements to start with. Things like 80 column display, real time clock support, MockingBoard support are within range (I will need to eBay a no-slot-clock). Maybe even RAM expansion boards (will need to learn about the various forms of bank-switching later )

For Speed reasons, you will want to Code the new Words in Machine Language.

 

The features not found in a Standard Apple //e or //c, should be Abstracted. Sound, Clock and Bank Switched Memory should be a Module or Library, so that if a different Device is Created, or needing to be Supported, a New Module or Library can be added.

 

Onward and upward !!

 

Hey!? Anyone trying out GraFORTH yet?

Not since 1986... ;) But I remember some of the Basics of it.....

 

Oh yeah!

You can check out "Inside the Apple IIe" by Gary B. Little here:

http://apple2online.com/index.php?p=1_13_Apple-II-IIe

I would further recommend both the GraFORTH and TransFORTH manuals:

 

 

http://www.virtualapple.org/docs/GraFORTH%20II%20Language%20Reference.pdf

http://www.virtualapple.org/docs/GraFORTH%20II%20Animation%20Guide.pdf

ftp://ftp.apple.asimov.net/pub/apple_II/documentation/programming/forth/TransFORTH ][b Reference Manual.pdf

 

MarkO

Edited by MarkO

Share this post


Link to post
Share on other sites

A Machine Language Interface needs to be defined, so that new Low Level Modules, areas that need to Optimized for Speed or Size and Specialized Hardware can be supported.

Share this post


Link to post
Share on other sites

Merry Christmas everyone (..or Happy Holidays.. whichever you perfer :-) !!

I have been doing a TON of reading and finally started doing some actual coding. Nothing to extensive as time for this project is limited.

I have been researching:
Double Hi-Res graphics
MockingBoard support
Clock support
RAM Card / Bank switching schemes
...and a few other minor oddities that caught my attention.



Double Hi-Res graphics
There is lots of good documentation on this...strangly almost none of it is on the Internet. Old books and magazines (Nibble specifically) have been key sources for this. DHRG requires very specific setup and exiting via use of the soft switches. Without a good clear guide this can get really messy. I have that information now. Drawing on the DHRG screen is a bit more complicated than standard HGR as calculations for Vertical position (just like HGR) and Horizontal positioning needs to be done. This makes it a tad slower than HGR. However, you get 16 FULL colors in DHRG and nice fine horizontal (560) dots in black and white. Also, for those with an accelerator (or an emulator :-) running at 3.7MHz makes DHRG quite snappy !


MockingBoard support
After reading a review in Nibble (May 1983 page 102) I discovered that adding support to the MockingBoard should be really easy. In addition, the MockingBoard included software includes a Sound Demo, a Sound Editor (not that great but it works), a Phoneme Editor (only usable with the Voice version) and several pre-created sounds. The pre-created sounds are not that great but many are OK. I found a copy of the software on Apple2Online.com.
The Nibble review stated that there were pre-written routines for developers to use in their programs but I did not find these in the Apple2Online archived version. I will check other archives to see what I can find.


Clock support
Looks to be as easy as reading a memory location... at least for time stamping anyway. Also discovered a really cool hack !!! A MOUSE CARD can be used as a clock ! The clock cards are essentually timers that trigger an interupt. The Mouse card does the same thing. I found out that tib bit and the code to do it in Nibble (January 1991 page 54). Looking forward to playing with that !!


RAM Card / Bank switching schemes
I have found 3 different schemes:
AUX (slot 0) RAM Cards:
-Use 64K banks
-Conform to the Apple 2e 64K Extended 80-column card bank switching

AUX Language Cards:
-use 16k banks

Peripheral-Slot Cards:
-Uses Apple memory expansion protocol first implemented in the 2e
-Bank switches a single byte at a time
-Expanded RAM can be treated as “block Storage” (aka one large contiguous block of RAM)
-RAM is accessed through the “Protocol Converter” ROM firmware and NOT directly to the RAM

Some RAM Cards such as the Saturn 128K RAM card (peripheral slot), apparently uses 16k banks. Pre-Apple 2e 128K RAM cards probably use 16k banks as that is how the Apple 2+ Language card was set up.

I have a RAMWorks 2 and A Saturn card for my real 2e so I will start there. Specifically with the RAMWorks. Just a note; "RAMWorks" is AUX slot and "RAMFactor" is Peripheral slot. All the Applied Engineering cards come with good software which includes RAM Disk software. ProDOS also has RAM Disk capabilities so either way, you can start utilizing your RAM card without writing any code.


Developing PONG in GraFORTH
It's one thing to discover all this stuff but quite another to implement it. I have chosen to write a PONG game to implement most of these things. I found a really simple PONG game written in Applesoft, so I will be recreating it in GraFORTH. It will serve as a comparison for coding style (Basic vs Forth) and speed (GraFORTH compiles to ASM so I suspect the GraFORTH version will be so fast as to be unplayable !!)
The first GraFORTH version (character graphics) will be as close to the Applesoft (low-res) version as reasonably possible.
From there I will rewrite it in HGR "Block" graphics, then in DHRG. From there I will start adding new components to the game to make it a "real" game. MockingBoard sound effects too :-)


Wrinkles and Oddities
I have been working exclusively in emulators for the time being. It's just so much faster and more flexible to do so. I do plan to use my 2e in the future.
I have been using Virtual 2 on my Mac and AppleWin on my PC. One significant oddity with AppleWin has been the inability to PASTE text to the Apple command line. This works in Virtual 2 but not in AppleWin.... what a PAIN!! It is SO FAST AND CONVEINENT to write code in a word processor then cut and paste it into the virtual machine. So much so, that I have chosen to write and archive my GraFORTH code on my Mac as text rather than on Apple 2 "disks".

I'm also writing some GraFORTH "Words" that will discover what Apple 2 you are using (by reading the values in $FBB3, $FBC0 and $FBBF) and what cards are installed in your Apple 2.
System configuration discovery routines could be very usefull later on.

  • Like 2

Share this post


Link to post
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...