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

    I have a source file now that replicates the original init.s (for the AIM-65) and assembles to the same bytes as the original BASIC V1.1 ROM.

    I have resisted the temptation to start hacking it now in favour of doing the mowing to keep peace and harmony in the house ...

    But I will be back on it later tonight... I can almost smell the finishing line!

    Dave

    Comment


      OK,

      Here is my first ugly (and probably buggy) attempt: https://drive.google.com/drive/folde...Ay?usp=sharing.

      Initialise the AH5050 ROM.
      Go back to the AIM-65 MONITOR.

      Enter the HEX bytes from the listing file into memory using the AIM-65 monitor. Start entering them at memory address 0270 (hex).

      When you have finished (and double checked them); invoke the AH5050 filer and PUT the memory from=0270 to=0370 file=INIBAS to the disk.

      After that, power cycle the AIM-65 (to make sure the RAM contents has 'evaporated'!).

      Initialise the AH5050 ROM as usual.

      Use the AH5050 Filer to RUN the file INIBAS (that we have just saved).

      With luck, you should be prompted (as normal) for the MEMORY SIZE and WIDTH. Just enter <RETURN> as usual. You should find yourself in BASIC ready to go - with the additional AH5050 commands available to you!

      Alternatively (and more likely) you will have a crash - but it will be interesting to see how far we get...

      If things go OK - I will finish off my commenting the code (the best I can), fix a bug I know is in there and remove a bit of code I believe is superfluous.

      Have fun . I am off for my walk now...

      Dave
      Last edited by daver2; May 2, 2021, 10:07 AM.

      Comment


        Looks nice, but that's a lot of typing & fooling around; got a .HEX file?

        BTW, interesting that your assembler lists a label cross reference but not the line numbers that it references

        Comment


          Mike,

          I’ll post a HEX file shortly. Sorry about that, I was pushed for time the other day...

          Yes, there does appear to be some bugs in asm80.com in the area of the cross-referencer .

          Dave

          Comment


            Mike,

            I have uploaded the source (a65), listing and HEX files for you to https://drive.google.com/drive/folde...Ay?usp=sharing.

            I have also taken the opportunity (wisely or not) to fix the two known issues with the code before someone tests it in earnest (or I have introduced two bugs)...

            1. I have changed RAMSTART2 and COLD_START to both be at address 0270. This maximises space for the BASIC program (by allowing it to start at 0270 instead of 0300 - well, 0271 rather than 0301 if you wanted to be pedantic). This means that the first byte of COLD_START will be overwritten with a 0 just before INIBAS bales out into BASIC. This should be OK as INIBAS is never subsequently used. Just make sure you save it to disk BEFORE running it! The previous RAMSTART of 0301 meant that some other byte within INIBAS got set to 0 depending upon the code itself. This way it is consistent and repeatable.

            2. A little bit of (what I think) is superfluous code has been commented out with double semicolons.

            I have also found the problem with asm80.com with regard to the cross-reference listing. For some reason, completely blank lines in the listing file have been 'eaten'. They are accounted for in the cross referenced line numbers however... I will make sure I don't use blank lines from now on! And I will report the finding to the asm80.com author.

            I await the bug reports...

            Dave

            Comment


              Dave,

              I will enter the bytes manually from the listing and make the INIBAS disk file and test this at the weekend.

              (The first version is still working fine for me, remembering to type NEW after re-entering BASIC)

              Hugo.

              Comment


                Looks good at a fast glance; very impressive indeed!

                Will test some more when I can.

                MOS version & dump attached.
                Attached Files

                Comment


                  Bug Report:

                  Not much if anything to report, probably just an aberration the very first time I tested it. I entered all the bytes manually and made the disk file, double checked they were correct. Ran the program, BASIC opens up normally.

                  I typed in an initial simple program,

                  10 FOR X = 1 TO 5
                  20 PRINT "INIBAS"
                  30 NEXT X
                  40 END

                  On LISTing it reported a syntax error in line 10, but there is not one.

                  So I tried again, but this time typed NEW after BASIC self opened. No problems.

                  But then here is the thing; I re-tried it again from scratch after power off re-running & listing the same program and others, I cannot duplicate that initial syntax error issue no matter how I try, and I don't have to type NEW either and Saving and Loading BASIC files works fine.So it seems that was an odd one off event.

                  I tested both SAVE/LOAD and SAVEB/LOADB, both work.

                  So right now I cannot find any bug in Dave's program and it appears to be working PERFECTLY !

                  ( I like the way the program sort of destroys itself after one use, somewhat analogous to the smoking magnetic tapes in Mission Impossible)
                  Last edited by Hugo Holden; May 6, 2021, 05:45 PM.

                  Comment


                    I'll put the initial problem down to 'finger trouble' of some kind.

                    Glad to hear that it is working though. Yes, I couldn't bear to loose a few tens of bytes on a small memory machine - and there was no need to keep the program after use either. My mission, should I choose to accept it and all that...

                    Give it a good test out at your convenience and report any problems. It would be good to test out the disk handling functions etc. to make sure they are working OK.

                    It still leaves the mystery of the SYS command though and why it potentially doesn't work. We can work on that one a bit later though. You never know - it may work now?

                    Just out of interest - has anyone got the FORTH ROMs installed on their AIM-65? I have found the entry point into the AH5050 for what appears to load up a file called FORTH (which I assume are the disk handling 'patches' for the FORTH ROMs). If no one is using FORTH - then there is not much point in looking at this though.

                    Dave

                    Comment


                      Dave,

                      Can you give a short example of executable code in memory, that would run via the SYS command in BASIC (I have not used SYS before) so that I can test out the SYS command ? or would SYS be expected to work with any BASIC program I had entered, if it was pointed to 0300h in this case ?

                      Hugo

                      Comment


                        SYS will only work with machine code programs.

                        I will make a little (simple) example for you tomorrow when the rains come!

                        The original problem was that SYS was not even being recognised and returned a SYntax error, so ‘in theory’ just typing SYS 0 from within BASIC as a command (as opposed to a program with a line number) will either result in a SYntax error (the SYS is not being recognised) or no SYntax error (in which case the SYS command is recognised correctly, but the AIM-65 will probably crash at this point).

                        Dave

                        Comment


                          Originally posted by daver2 View Post
                          I'll put the initial problem down to 'finger trouble' of some kind.

                          Glad to hear that it is working though. Yes, I couldn't bear to loose a few tens of bytes on a small memory machine - and there was no need to keep the program after use either. My mission, should I choose to accept it and all that...

                          Give it a good test out at your convenience and report any problems. It would be good to test out the disk handling functions etc. to make sure they are working OK.

                          It still leaves the mystery of the SYS command though and why it potentially doesn't work. We can work on that one a bit later though. You never know - it may work now?

                          Just out of interest - has anyone got the FORTH ROMs installed on their AIM-65? I have found the entry point into the AH5050 for what appears to load up a file called FORTH (which I assume are the disk handling 'patches' for the FORTH ROMs). If no one is using FORTH - then there is not much point in looking at this though.

                          Dave
                          I believe my AIM has the Forth ROM but I've not turned it on for years. I relatively sure it is a version of FIG Forth. If so, all of the important I/O operations would be vectored through USER variables. This would make sense that the disk would contain a patch address to the mass storage or input functions. The disk would most likely contain source code, rather than machine code that it would load of the first read. That would setup the rest of the code to then use the disk for mass storage.
                          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.
                          Often I would reserve the first few 1K blocks to keep track of load blocks and a one line comment on what was there. If it needed more comment, that could be intermixed with the source.
                          A different way of thinking.
                          Dwight

                          Comment


                            Hugo,

                            The simplest thing would be to run INIBAS and go into BASIC.

                            Enter a very, very simple BASIC program of your choosing (e.g. 10 PRINT "Hello Hugo!") and RUN it.

                            If that is OK, try entering the command SYS(57535) from the command line (not as a BASIC program).

                            If the machine resets, then the extra commands buried within the AH5050 firmware may now be working.

                            If you get a SYNtax error, then the additional commands are not working as we expect.

                            57535 (in decimal) is $E0BF - which is the RSET (ReSET) entry point of the monitor when you power the machine up or hit the RESET button.

                            Dave

                            Comment


                              Originally posted by daver2 View Post
                              SYS will only work with machine code programs.

                              The original problem was that SYS was not even being recognised and returned a SYntax error, so ‘in theory’ just typing SYS 0 from within BASIC as a command (as opposed to a program with a line number) will either result in a SYntax error (the SYS is not being recognised) or no SYntax error (in which case the SYS command is recognised correctly, but the AIM-65 will probably crash at this point).
                              Hi, Dave,

                              I've been offline for a few days due to some immediate things that have come up, but popping in to see where the conversation has gone, as best I can tell from my disassembly of the AH5050 ROM, the SYS command is essentially the same as the version from MS BASIC on the PET (and I believe I posted about that earlier). Of course the MS implementation isn't part of the AIM-65 BASIC ROMs, so it's handled by the token dispatcher in the AH5050 firmware. It's 3 instructions. On the PET, both 'SYS 1024' and 'SYS(1024)' produce the same result, which is to jump to the BRK at the start of BASIC ($0400) which dumps you into the TIM monitor in ROM (if on a model where that's present). SYS 0 will jump you to the USR() vector, which until the user changes it, points to the "?ILLEGAL QUANTITY ERROR" handler.

                              I used to use the SYS command quite frequently on the PET and the C-64 (the C-64 implementation is more complex and will stuff the .A, .X, and .Y registers from where BASIC can POKE some values, letting you do quite interesting things from BASIC). I've started dabbling with SYS on the AH5050 firmware and I'm getting the same results that you are, which is to say ?SN ERROR". I am unsure why this is happening as I've only dug down one layer.

                              I'm also unable to get the STATUS command to work as documented in the manual. Everything else appears to be working as expected.

                              I have a couple of test programs that are unfinished. I hope to find some time this week to get back to things.

                              -ethan

                              Comment


                                Originally posted by daver2 View Post
                                If that is OK, try entering the command SYS(57535) from the command line (not as a BASIC program).
                                Hi, Dave,

                                I believe this will not work, intentionally, as none of the new AH5050 commands work from the command line. There's a stack check in the AH5050 firmware TOKDSP routine to probe the stack to see who the caller of CHRGET was and if it's $B28D (BASIC label RESTART + $E, which is a call to CHRGET inside RESTART. If found, it does its own calls to crunch and store the line of BASIC, due to the new tokens that the ROM routine couldn't handle.

                                This is different than a lot of CBM ROM wedges which do _not_ extend BASIC by adding tokens. They use a new command marker char (like '*') to intercept the command stream from normal CHRGET processing and then what follows is raw ASCII/PETSCII, not tokenized anything. It's a completely different approach. I'm pretty sure the approach taken by the AH5050 firmware precludes command line (immediate mode) processing of new commands, only that it will tokenize the new commands or execute those tokens in a line of stored BASIC.

                                It's kind of a pain as I definitely find OPEN/CLOSE and SYS to be useful from the command line. Commands that do input do not work from the command line, intentionally, because the live command buffer and INPUT use the same block of RAM so you can't do one while you are doing the other.

                                -ethan


                                Comment

                                Working...
                                X