#8 Possible overflow bug in hex generator

[J.B.]

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.

[Jay Cotton]

Do you have a test case for this? It looks like DBL.HEX from the side by side comparision. The newer (more broken) version of the assembler should have fixed this also. Can you retest.

[J.B.]

It's this version of dbl.asm that I modified not to wrap around: https://github.com/jblang/z80ctrl/blob/master/dbl.asm

It still generates the all-zero lines after pulling down the patch. I think maybe the bug is only triggered if the last byte assembled falls exactly on FFFF.

The original version of DBL.ASM from http://altairclone.com/downloads/roms/DBL.ASM does not reproduce this issue now and assembles with the warning as you stated in the other bug.

[Jay Cotton]

I'll have a look at your .asm file, but look at this one.
org 0fff0h
db "This is a test of"
end
produces
$ asm8080 eom.asm -l
*** Warning 17 in "eom.asm" @2: address wrapped at maxval

$ cat eom.hex
:00000001FF

If I shorten it by 1 byte, it seems to be happy. So, over flow it busting the code....

[Jay Cotton]

Get your code and did a test. Yep. I think we are abusing the hex generator a bit.
I modified your code to (what I think the correct text should be)
;---------------------------------------------------------------
;DISK BUFFER IN RAM RIGHT AFTER THE LOADER
;---------------------------------------------------------------
BUFFER: DW 00H ;FILLS THE EPROM OUT WITH 00'S
org 0

;---------------------------------------------------------------
; AND FINALLY THE STACK, WHICH GROWS DOWNWARD
;---------------------------------------------------------------
STSP: DS 00H ;SPACE FOR STACK
ds 08ch
STACK: EQU $

    END

No warnings, and the hex file is nice and short.

BTW: Did my code help you get your project running? Its a cool project...

[J.B.]

You're right.. this code is not optimal. I've found a lot of questionable sources on altairclone.com that break your assembler. Another example is HEXLOAD.ASM which is trying to use the "ret" mnemonic to load the opcode for that instruction into L:

        lxi     h,ret           ;H=0, L=RET instruction

I'm not sure if any of these things are really worth accomodating. I'm curious what assembler they're using that lets them get away with this.

And yes, your assembler has been very helpful for experimenting with old sources writen in the Intel syntax. My goal is to write AVR code so that it's transparent to the code running on the Z80 and I can run the original binaries, but it is nice to have a cross assembler to experiment with the sources. The first computer I used at around age 7 was my dad's Heathkit H89 so I've got a lot of nostalgia for the Z80 and for CP/M.

[J.B.]

I spent some time today looking at the CP/M manual' ASM chapter: https://www.tramm.li/i8080/cpm22-m.pdf. It explicitly states that labels are case insensitive (page 79) and that machine instructions can be used in the operand field (page 82). So what I thought were questionable constructs are actually valid according to that assembler. If your aim is to be as compatible with old sources as possible, maybe it's worth perusing.