Announcement

Collapse

Forum etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


"PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

1541 Drive & AIM-65 help.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by Dwight Elvey View Post
    This is only a guess. Most early Forths don't setup the disk into file. instead they would consider the disk as a number of addressable storage blocks of 1K in size. These can be used for source code or raw binary, as the user would like. It was up to the user to keep track of where things were. Source text could be easily link together as a continuous source.
    Hi, Dwight,

    I have a little experience with Forth, but only in a few places, and definitely not anything fully-featured (places like the Boot ROMs of a Sun workstation or a VIC-20 from Forth in a ROM cartridge). That said, I do have a lot of experience in the guts of Commodore disk drives and since CBM program and sequential files only have forward pointers, you can't seek back and forth in them without essentially buffering the entire pointer chain and using direct access commands (U1/U2) to read raw blocks. This and your observations coupled with the reference to a FORTH,L file in the AH5050 firmware leads me to believe that the 1K block scheme was implemented using CBM DOS REL files which _do_ have different block-chain scheme and can be treated as a series of arbitrary-sized block records, each with their own block address.

    Unfortunately, outside of some initialization code in the firmware which endeavors to open and import some bytes from FORTH,L, there's no further firmware support which makes me think that there used to be a necessary bootstrap file, named FORTH, that contained some essential support code for users to call upon to save and load their own Forth program.

    I don't know for a fact that there is essential code in this supposed FORTH,L file but it does seem highly likely.

    -ethan

    Comment


      Originally posted by erd View Post

      Hi, Dwight,

      I have a little experience with Forth, but only in a few places, and definitely not anything fully-featured (places like the Boot ROMs of a Sun workstation or a VIC-20 from Forth in a ROM cartridge). That said, I do have a lot of experience in the guts of Commodore disk drives and since CBM program and sequential files only have forward pointers, you can't seek back and forth in them without essentially buffering the entire pointer chain and using direct access commands (U1/U2) to read raw blocks. This and your observations coupled with the reference to a FORTH,L file in the AH5050 firmware leads me to believe that the 1K block scheme was implemented using CBM DOS REL files which _do_ have different block-chain scheme and can be treated as a series of arbitrary-sized block records, each with their own block address.

      Unfortunately, outside of some initialization code in the firmware which endeavors to open and import some bytes from FORTH,L, there's no further firmware support which makes me think that there used to be a necessary bootstrap file, named FORTH, that contained some essential support code for users to call upon to save and load their own Forth program.

      I don't know for a fact that there is essential code in this supposed FORTH,L file but it does seem highly likely.

      -ethan
      I basically agree, Ethan. It make perfect sense. The only difference is that such a file is more likely in Forth source format and not machine code. Machine code would tie it to a specific revision of Forth while Source would be more flexible. There would be less need to use specific addresses in the Forth on ROM. Like I said, fig Forth has specific named locations for various I/O functions. Things like disk I/O, key board or output are all easily re-vectored from source level code. There may be additional machine code loaded but for the attachments to the Forth ROM, it would make more sense to do that part a source. Additional machine code would likely just be a preassembled chunk of code moved to RAM by the source code. That is basically how I'd do it.
      Remember, Forth is both a compiler and an interpreter. Both could be used to attach new functions to the existing Forth. Precompiled code is less flexable.
      Dwight

      Comment


        Ethan,

        Welcome back. Yes, life does get in the way sometimes...

        Just thinking aloud...

        So, does that mean that we can use SYS(n) from within a BASIC program. As you state, less useful than the ability to perform it from the command line as well - but we are looking to recreate the original intent of the AH5050 firmware.

        With regard to FORTH, the entry point into the AH5050 firmware to load the FORTH,L file is at a fixed entry point. The (logical) way to get there would be from FORTH itself via a JSR instruction. The other way would be to load (and execute) something like INIBAS - but called INI4TH (say) - from the AH5050 filer (or the STARTUP file). This could initialise FORTH and somehow call the AH5050 firmware to load the FORTH,L file.

        As there is nothing in the AH5050 manual, we have to make it up ourselves...

        I suspect Dwight is correct about the FORTH,L file being FORTH code - a gut feeling.

        It would also be useful to come up with a machine code test routine for the AH5050 firmware subroutines - as this is what FORTH would probably use under the hood.

        Dave

        Comment


          I do have all the language ROMs in my AIMs, so if anything needs testing I could do it as long as I get specific detailed instructions; Forth has never captivated my interest so my knowledge is extremely limited.

          Comment


            Just to confirm.

            When I tried SYS(57535) from the command line it reported FC Error.

            SYS(0) at the command line reports SN Error.

            I tried SYS(57535) in a program line, and running the program, and it reports SN Error in that program line.

            Comment


              Originally posted by daver2 View Post
              So, does that mean that we can use SYS(n) from within a BASIC program. As you state, less useful than the ability to perform it from the command line as well - but we are looking to recreate the original intent of the AH5050 firmware.
              More, I think, to be rediscovering how the original AH5050 firmware worked. I have source with 90% meaningful labels that recompiles, so it's entirely possible to consider extending functionality/fixing bugs.

              Originally posted by daver2 View Post
              With regard to FORTH, the entry point into the AH5050 firmware to load the FORTH,L file is at a fixed entry point. The (logical) way to get there would be from FORTH itself via a JSR instruction. The other way would be to load (and execute) something like INIBAS - but called INI4TH (say) - from the AH5050 filer (or the STARTUP file). This could initialise FORTH and somehow call the AH5050 firmware to load the FORTH,L file.

              As there is nothing in the AH5050 manual, we have to make it up ourselves...
              Yes. It's not clear to me what the linkage is between FORTH and the AH5050 FORTH entry point, but I know nothing about the FORTH implementation on the AIM-65.

              Originally posted by daver2 View Post
              I suspect Dwight is correct about the FORTH,L file being FORTH code - a gut feeling.

              It would also be useful to come up with a machine code test routine for the AH5050 firmware subroutines - as this is what FORTH would probably use under the hood.
              The part I'm puzzling with is how FORTH would continue to get blocks from the REL file after the AH5050 firmware hands off to what it's loading.

              In LOD4TH, it does this:
              Code:
              LDY DATAV
              STY TEMP2
              LDY DATAV+1
              DEY
              STY TEMP2+1
              LDY #$fc ; 252 .
              LDX #$02 ; 2 .
              Ld403: LDA FORJMP,X
              STA (TEMP2),Y
              DEY
              DEX
              BPL Ld403
              INC TEMP2+1
              RTS
              The label DATAV is the vector in the BASIC ROM for the DATA token. I have to think it's something else in the FORTH ROM if that's at the same address as an alternative language choice. It just happened to match the MS BASIC listing so I snarfed the label. It's probably _not_ DATA.

              In any case, this block takes the vector from there and does a little fiddling to copy a JMP FORINI to some offset of that vector which may be how it hooks in the next stage.

              The odd thing is that the second thing FORINI does is to call LOD4TH, which was presumably called earlier, so perhaps it's repairing being overwritten every time?

              I see _what_ all this init code is doing, but without more understanding of what it's copying from, I don't know _why_ this is meaningful.

              -ethan




              Comment


                Originally posted by Hugo Holden View Post
                Just to confirm.

                When I tried SYS(57535) from the command line it reported FC Error.

                SYS(0) at the command line reports SN Error.

                I tried SYS(57535) in a program line, and running the program, and it reports SN Error in that program line.
                Hi, Hugo,

                Interesting observations. Thanks for sharing. I've gotten similar results. IIRC, FC Error has to do with the function evaluation code not finding a parenthesis where it's expecting one (missing open or close paren, depending on context). I have never gotten anything but errors trying from BASIC lines or from the command line. Given that the actual implementation of SYS is JSR/JSR/JMP (which is *exactly* how it works on the PET), and it's essentially evaluating a formula, converting it to an integer, then jumping to that integer as an address, there's not many places for it to go wrong. I'm kinda stumped how it could fail.

                I'm considering how to set this up in emulation so it's easier to mod the ROMs or trace BRK instructions or some other debugging technique.

                Same for STATUS which doesn't work as documented.

                -ethan

                Comment


                  Originally posted by erd View Post

                  there's not many places for it to go wrong. I'm kinda stumped how it could fail.

                  -ethan
                  Hi Ethan,

                  I'm never surprised when software fails and most of the time I'm amazed how well many programs work, with the many small steps and only one tiny error to upset the apple cart. Most of the software trouble I get is PBKC issues...problem between keyboard and chair.

                  Comment


                    I've run across this before, but had occasion to stumble across it again - the original commented source for MS BASIC for 6502, published by Microsoft. The real gem here is the content of the original comments. They do call out the use of the carry flag to denote digits and the zero flag as an end-of-statement marker, which we all had to painfully rediscover.

                    https://www.pagetable.com/docs/M6502.MAC.txt

                    Comment


                      A couple of years ago a VCFED member made a 'tweak' to a DEC PDP-8 OS/8 device driver to support a parallel paper tape reader (if I remember correctly). We accidentally stumbled over a 'feature' in there left from the 1960's...

                      Isn't vintage computing fun...

                      It's working (now)!

                      Dave

                      Comment


                        One thing I'm reminded of while looking over this original source code. Certain commands, mostly I/O, were not implemented by Microsoft. They put hooks into system calls that the platform manufacturer had to provide (it's why there's a long jump table in the PET ROMs - it's the API between MS BASIC and the CBM kernal). SYS is one of the ones that Microsoft didn't implement. They just see the SYS token and make a jump through a fixed address. That JSR/JSR/JMP code I mentioned was completely Commodore's implementation (and is echoed verbatim, allowing for different function addresses, in the AH5050 firmware).

                        But even though the SYS implementation code calls BASIC support routines directly, it's nowhere to be found in the MS BASIC sources.

                        -ethan

                        Comment


                          Originally posted by erd View Post

                          That JSR/JSR/JMP code I mentioned was completely Commodore's implementation (and is echoed verbatim, allowing for different function addresses, in the AH5050 firmware).

                          But even though the SYS implementation code calls BASIC support routines directly, it's nowhere to be found in the MS BASIC sources.

                          -ethan
                          I'm interested in the makers of the AH5050 system, ABM Systems from Silverbrook Tustin CA. (Their ABM font looks a little like IBM).

                          Presumably their software engineers made the AH5050 ROM program, but maybe they had a lot of help from Commodore, since it was specifically for the 1541 drive. I'm not sure what happened to this company, or if they made any other interesting products. In the manual / data sheet page 2 it also shows a photo of an RM-65 pcb of some sort next to a 1541 drive which is odd.

                          Comment


                            Originally posted by Hugo Holden View Post

                            I'm interested in the makers of the AH5050 system, ABM Systems from Silverbrook Tustin CA...

                            Presumably their software engineers made the AH5050 ROM program, but maybe they had a lot of help from Commodore, since it was specifically for the 1541 drive.
                            Commodore was not famous for working with third-party hardware companies. I think the "help" ABM got was to copy swaths of either the VIC-20 or C-64 kernel ROM. I found huge sections of the file I/O and especially the bit-level IEC routines that are instruction-for-instruction verbatim from CBM ROMs. The only major deviation I've found was that CBM OPEN lets you specify your own secondary address, and AH5050 OPEN assumes the secondary address from the file address (OPEN 2,8,2 vs OPEN 2,D1). The SA is still sent because devices need them. The device numbers themselves are hidden from the user, but disk drives are still at bus addresses 8, 9, 10, and 11, so there's a conversion layer.

                            -ethan

                            Comment


                              Ethan,

                              You are mentioning files (back in posts #306 - LOD4TH and FORINI) that I have not seen or heard of before...

                              Dave

                              Comment


                                Originally posted by daver2 View Post
                                Ethan,

                                You are mentioning files (back in posts #306 - LOD4TH and FORINI) that I have not seen or heard of before...
                                Sorry. Those are arbitrary labels in the firmware disassembly I have here. I made them up to fit with the code blocks they are the entry points to. I thought I had previously posted the code with the labels in them, but perhaps that was in an e-mail to some of the people here.

                                -ethan


                                Comment

                                Working...
                                X