Intel 8080 Assembler / Bugs / #6 Problems with altmon.asm

Jay Cotton - 2018-01-13

Thanks for the report. I'll take a look at this, and get that source file
to play with.

There have been a few bugs fixed in this area, looks like I missed a few.

jc

On Fri, Jan 12, 2018 at 7:33 PM, J.B. jblang@users.sf.net wrote:

[bugs:#6] https://sourceforge.net/p/asm8080/bugs/6/ Problems with
altmon.asm*

Status: open
Group: v1.0 (example)
Created: Sat Jan 13, 2018 03:33 AM UTC by J.B.
Last Updated: Sat Jan 13, 2018 03:33 AM UTC
Owner: nobody

I wanted to report a source that won't assemble cleanly:
http://altairclone.com/downloads/roms/Altair%20Monitor/ALTMON.ASM

It chokes on line 148:

lxi h,cmdTbl+100h-2*'B' ;'B' indexes to start of cmdtbl

*** Error 15 in "altmon.asm" @148: Operand over range! (4211526)

Putting parentheses around 2*'B' fixes it:

lxi h,cmdTbl+100h-(2*'B') ;'B' indexes to start of cmdtbl

It's also complaining about unknown labels that differ in case (doboot vs
doBoot, hexload vs hexLoad):

Error 0 in "altmon.asm" @161: Label not found! ("doboot") Error 0 in "altmon.asm" @167: Label not found! ("hexLoad")*** Error 0 in "altmon.asm" @171: Label not found! ("hexLoad")

Apparently whatever was originally used to assemble this source was not
case sensitive.

Finally, it doesn't complain about lines like this, but assembles them
incorrectly:

db 'BOO','T'+80h.

This assembles to 42 4F 4F 54 80 when it should assemble to 42 4F 4F D4.

Again adding parentheses fixes the problem: db 'BOO',('T'+80h).

After making these changes it assembles identically to the original hex
dump here: http://altairclone.com/downloads/roms/Altair%
20Monitor/ALTMON.HEX

Making these changes wasn't hard but if you're aiming to be compatible
with historical sources, I thougth you may want to fix this.

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/asm8080/bugs/6/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

Related

Bugs: #6

alternate
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Cotton - 2018-01-13

I have confirmed your bug report. The hexLoad bug, is a source error. The label is called hexload (lower case L) I wonder how that gets through the assemblers...

Things like 'I'+80h should work, so I'll have a go at those things first...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

J.B. - 2018-01-15

Yes, I found the case mismatch and fixed it in my source. I am assuming whatever was originally used to assemble it was not case senstive.

I found another weird one that will not assemble: http://altairclone.com/downloads/roms/DBL.ASM.

asm8080 will not accept it because the DS 84H and DS 08H at the end causes it to go past the top of RAM at FFFF:

*** Error 17 in "DBL1.ASM" @397: Program counter over range! (0) *** Error 17 in "DBL1.ASM" @402: Program counter over range! (132)

I changed 84H and 08H to 00H, and it assembled successfully, but then the STACK label is wrong, pointing to 0000H instead of 008CH. Looking at the original listing, apparently from the original assembler allows the PC to wrap back around to 0:

```
;---------------------------------------------------------------
;DISK BUFFER IN RAM RIGHT AFTER THE LOADER
;---------------------------------------------------------------
FFFE 0000 BUFFER: DW 00H ;FILLS THE EPROM OUT WITH 00'S
0000 DS 84H

;--------------------------------------------------------------- ; AND FINALLY THE STACK, WHICH GROWS DOWNWARD ;---------------------------------------------------------------

0084 STSP: DS 08H ;SPACE FOR STACK
008C = STACK: EQU $

008C END
```

http://altairclone.com/downloads/roms/DBL.PRN

Last edit: J.B. 2018-01-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

J.B. - 2018-01-15

I fixed it by hardcoding STACK: EQU 008CH. However, I'm also seeing something weird with the hex file that is generated. The 256 bytes from the program are in there twice (once at the beginning and once at the end:

:10FF00002113FF11002C0EEB7E1223130DC208FFEC :10FF1000C3002CF3AFD3222FD3233E2CD3223E0396 :10FF2000D310DBFFE6100F0FC610D31031792DAFC1 :10FF3000D308DB08E608C21C2C3E04D309C3382CC6 :10FF4000DB08E602C22D2C3E02D309DB08E640C2E4 :10FF50002D2C11000006003E10F5D5C5D511868068 :10FF600021EB2CDB091FDA502CE61FB8C2502CDB2A :10FF700008B7FA5C2CDB0A77231DCA722C1DDB0A3A :10FF80007723C25C2CE111EE2C0180001A77BEC2EF :10FF9000CB2C804713230DC2792C1AFEFFC2902C64 :10FFA000131AB8C1EBC2C22CF1F12AEC2CCDE52C0E :10FFB000D2BB2C040478FE20DA442C0601CA442C5F :10FFC000DB08E602C2AD2C3E01D309C3422C3E80C1 :10FFD000D308C30000D1F13DC2462C3E43013E4D43 :10FFE000FB320000220100473E80D30878D301D3C2 :10FFF00011D305D323C3DA2C7ABCC07BBDC9000062

In between, it has 8160 lines that are all zeros like this:

:1000000000000000000000000000000000000000F0 ... :10FEF0000000000000000000000000000000000002

They go all the way from 0000 to FEF0. Maybe having the PC go right up to FFFF has confused the hex generator? The .bin file looks normal though, just 256 bytes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Jay Cotton - 2018-01-15
  
  Thats a new bug. Can you file a ticket on it....
  
  On Mon, Jan 15, 2018 at 3:02 PM, J.B. jblang@users.sf.net wrote:
  
  I fixed it by hardcoding STACK: EQU 008CH. However, I'm also seeing
  something weird with the hex file that is generated. The 256 bytes from the
  program are in there twice (once at the beginning and once at the end:
  
  :10FF00002113FF11002C0EEB7E1223130DC208FFEC
  :10FF1000C3002CF3AFD3222FD3233E2CD3223E0396
  :10FF2000D310DBFFE6100F0FC610D31031792DAFC1
  :10FF3000D308DB08E608C21C2C3E04D309C3382CC6
  :10FF4000DB08E602C22D2C3E02D309DB08E640C2E4
  :10FF50002D2C11000006003E10F5D5C5D511868068
  :10FF600021EB2CDB091FDA502CE61FB8C2502CDB2A
  :10FF700008B7FA5C2CDB0A77231DCA722C1DDB0A3A
  :10FF80007723C25C2CE111EE2C0180001A77BEC2EF
  :10FF9000CB2C804713230DC2792C1AFEFFC2902C64
  :10FFA000131AB8C1EBC2C22CF1F12AEC2CCDE52C0E
  :10FFB000D2BB2C040478FE20DA442C0601CA442C5F
  :10FFC000DB08E602C2AD2C3E01D309C3422C3E80C1
  :10FFD000D308C30000D1F13DC2462C3E43013E4D43
  :10FFE000FB320000220100473E80D30878D301D3C2
  :10FFF00011D305D323C3DA2C7ABCC07BBDC9000062
  
  In between, it has 8160 lines that are all zeros like this:
  
  :1000000000000000000000000000000000000000F0
  ...
  :10FEF0000000000000000000000000000000000002
  
  They go all the way from 0000 to FEF0. Maybe having the PC go right up to
  FFFF has confused the hex generator? The .bin file looks normal though,
  just 256 bytes.
  
  [bugs:#6] https://sourceforge.net/p/asm8080/bugs/6/ Problems with
  altmon.asm*
  
  Status: open
  Group: v1.0 (example)
  Created: Sat Jan 13, 2018 03:33 AM UTC by J.B.
  Last Updated: Mon Jan 15, 2018 10:49 PM UTC
  Owner: nobody
  
  I wanted to report a source that won't assemble cleanly:
  http://altairclone.com/downloads/roms/Altair%20Monitor/ALTMON.ASM
  
  It chokes on line 148:
  
  lxi h,cmdTbl+100h-2*'B' ;'B' indexes to start of cmdtbl
  
  *** Error 15 in "altmon.asm" @148: Operand over range! (4211526)
  
  Putting parentheses around 2*'B' fixes it:
  
  lxi h,cmdTbl+100h-(2*'B') ;'B' indexes to start of cmdtbl
  
  It's also complaining about unknown labels that differ in case (doboot vs
  doBoot, hexload vs hexLoad):
  
  Error 0 in "altmon.asm" @161: Label not found! ("doboot") Error 0 in "altmon.asm" @167: Label not found! ("hexLoad")*** Error 0 in "altmon.asm" @171: Label not found! ("hexLoad")
  
  Apparently whatever was originally used to assemble this source was not
  case sensitive.
  
  Finally, it doesn't complain about lines like this, but assembles them
  incorrectly:
  
  db 'BOO','T'+80h.
  
  This assembles to 42 4F 4F 54 80 when it should assemble to 42 4F 4F D4.
  
  Again adding parentheses fixes the problem: db 'BOO',('T'+80h).
  
  After making these changes it assembles identically to the original hex
  dump here: http://altairclone.com/downloads/roms/Altair%
  20Monitor/ALTMON.HEX
  
  Making these changes wasn't hard but if you're aiming to be compatible
  with historical sources, I thougth you may want to fix this.
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/asm8080/bugs/6/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: #6
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Jay Cotton - 2018-01-16
  
  Did not see the hex file problem on altmon. But the hex dumper may have an overflow bug.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Cotton - 2018-01-15

So the basic issues with 'I' + 80h and 2 * 'B' is operator presidence. The parser is chewing through the input text left to right one item at a time.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Cotton - 2018-01-15

lxi h,cmdTbl+100h-2*'B' ;'B' indexes to start of cmdtbl

The bug here is the assumption that 2 * 'B' get evaluated first befor cmdTbl+100h. The fix in the source is as stated cmdTbl+100h-(2*'B')

I'll have to think on this for a while to find a solution that works with the delep parser and stack down eval.

While looking at this bug I also see another one 'I'+80h is not working correctly.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Cotton - 2018-01-16

The db '1'+80h looks like there is a missing call to eval. Will look at it more.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Jay Cotton - 2018-01-16
  
  braceing like this ('I'+80h), gets around the problem.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

J.B. - 2018-01-16

I filed new bugs for the other problems.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Problems with altmon.asm

Group

Searches

Help

#6 Problems with altmon.asm

Related

Discussion

Related

Related