Some odd behavior out of AM2

General discussions related to the Altair 8800 Clone

Some odd behavior out of AM2

Postby pngwen » March 14th, 2017, 4:05 pm

I have been spending a lot of time with the MITS Programming System II package, and I am getting some odd behavior out of AM2.

I have my altair clone set up to have no ROM, so I am using the full 64K of memory. The layout I am attempting to use goes like this:

Code: Select all
          0 Bottom of Memory
        100 Monitor
       5100 Editor
      11520 AM2
            Symbol Table
     110000 Start of Editor Buffer
     147377 End of Editor Buffer
     160000 Start of User Space


The trouble is that when I try to set my program start assembling at 160000Q, it always has a symbol table overflow error at the first label.

This strikes me as odd because the manual says that the symbol table for AM2 begins at address 17006Q and grows upwards. My layout should provide it with about 45KB of
space, which should be plenty!

Playing around a bit, I discovered that if I put my program earlier in memory it works. I tried (20000Q, 100000Q, and 110000Q). Once I get to 120000Q, it starts to overflow, and continues to do so for the rest of memory. The program I am testing is a very small one which simply puts the numbers 1-10 in memory, and contains only 2 symbols.

Does anyone know for sure where the symbol table actually resides? It seems odd that it would have somehow claimed such a high address, especially given that very few of the original altairs of the period had RAM that far up.

BTW, what I am doing is writing the operating systems homework which I am currently giving to my students on my altair. They are writing a UNIX-Like system on an x86, and I am following suit on my clone. I have some ideas about how I am going to handle context switching and relocation, but a lot of them depend on my placing my kernel at the end of memory. I think 8K will be more than enough to house my toy OS, but I would like to get it set up so it can be resident with mon, am2, and edt. Any help/advice would be greatly appreciated!

Also, if you are interesting my OS assignments check out my wiki at https://cs.maryvillecollege.edu/wiki/Os/spring2017
pngwen
 
Posts: 14
Joined: July 7th, 2016, 9:57 am

Re: Some odd behavior out of AM2

Postby AltairClone » March 15th, 2017, 11:15 am

If you use all the default addresses and do not patch the edit buffer location, then you should be able to write and assemble a small program without any problem.

The default edit buffer location is 10662Q leaving about 414 decimal bytes of program source space before bumping into the AM2 assembler at 11520Q

The AM2 symbol table starts at 17006Q leaving about 500 decimal bytes before running into a typical user program start address of 20000Q.

Mike
AltairClone
Site Admin
 
Posts: 632
Joined: April 5th, 2013, 10:55 am

Re: Some odd behavior out of AM2

Postby pngwen » March 15th, 2017, 12:55 pm

Right, but what I'm seeing doesn't seem to jive with that. I'm trying to assemble to very high memory where the assembler would think it has about 49,000 decimal bytes for its symbol table, and yet it overruns at the first symbol. Take for instance this AM2 session:

Code: Select all
  ?AM2(S)


*ASM*
A_ORG 160000Q
START:  DI
Q#START:        DI
  ?


I noticed that this behavior starts around 120000Q. Do you think AM2 may have some sort of bug when dealing with very high memory addresses? One thing that may not come through on the forum is the the number of digits I'm using.

Code: Select all
017006Q  ; symbol table
160000Q  ; My origin
pngwen
 
Posts: 14
Joined: July 7th, 2016, 9:57 am

Re: Some odd behavior out of AM2

Postby AltairClone » March 15th, 2017, 4:55 pm

Wouldn't surprise me if there was a bug of some sort with high address values since, in the day, those were probably never used!

However, as I mentioned, for the simple program you are trying to write, you should be able to edit, assemble, and run at 20000Q without changing any settings for the edit buffer location, etc. Try that and let me know if that works for you.

Mike
AltairClone
Site Admin
 
Posts: 632
Joined: April 5th, 2013, 10:55 am

Re: Some odd behavior out of AM2

Postby pngwen » March 16th, 2017, 3:50 pm

Yeah, that does work just fine. For my simple program that's no problem, but for my Unix-like OS it's not enough room. What I have settled on is assembling the kernel at 40000. I then have a simple program to move the kernel into position at the end of memory for testing.

If time permits I may try disassembling portions of AM2 to figure out where it goes astray. It is definitely odd though. I did verify that the symbol table is really living where it is advertised to be at, and I have explored its structure a little bit. I will need that for when I use AM2 to build relocatable apps. (I am going to write a linker loader next week to help with this.)

On the whole, this isn't a bad environment for writing an OS. I can work from the monitor, assemble, move, and then jump into my kernel. For now my kernel only contains a console driver and a machine code monitor so it doesn't hurt anything in the MITS system. When I'm done testing it, I can then just stop, reset, and then examine/exec address 100 to get back into the monitor. Also, single stepping my kernel on the front panel is a lot of fun!
pngwen
 
Posts: 14
Joined: July 7th, 2016, 9:57 am

Re: Some odd behavior out of AM2

Postby AltairClone » March 18th, 2017, 10:18 am

Regarding the problem that programs ORG'd at 120000Q and above give symbol table overflow errors, I haven't yet disassembled AM2 to find the exact instruction and location, but it is apparent what the problem is:

To check for symbol table overflow, the assembler compares the symbol table insert pointer (let's call it pInsert) to the user program ORG location (let's call it pgmOrg). Instead of testing for borrow from this subtraction, it appears they are checking the "M"inus flag instead:

Code: Select all
Compare user program origin to the symbol table insert pointer (pgmOrg - pInsert)

110000Q - 17006Q = 70772Q (msb NOT set)
120000Q - 17006Q = 100772Q (msb IS set, though not because pInsert > pgmOrg)



I may disassemble the code later to find this comparison and see if it's as simple to fix as changing a JM instruction to a JC instruction.

Mike
AltairClone
Site Admin
 
Posts: 632
Joined: April 5th, 2013, 10:55 am

Re: Some odd behavior out of AM2

Postby AltairClone » March 18th, 2017, 12:42 pm

After a quick look at disassembled code, the bug is very easy to fix. After loading the monitor, editor and AM2, use the monitor to EXM 13655. It should show 372 (JM instruction). Use DEP 13655 to change the 372 to a 332 (JC instruction). Then you can use addresses above 110000Q.

You can save the patched version of AM2 if you want this change permanent.

Mike
AltairClone
Site Admin
 
Posts: 632
Joined: April 5th, 2013, 10:55 am

Re: Some odd behavior out of AM2

Postby pngwen » March 20th, 2017, 10:11 pm

Excellent! I suppose it makes sense that whoever wrote ASM/AM2 wouldn't have caught that sign bit error. After all, that's a lot of RAM for an Altair.

Thank you for the patch!
pngwen
 
Posts: 14
Joined: July 7th, 2016, 9:57 am


Return to General Discussions

Who is online

Users browsing this forum: No registered users and 17 guests

cron