SourceForge has been redesigned. Learn more.
Close

Activity for J.B.

  • J.B. J.B. posted a comment on ticket #8

    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.

  • J.B. J.B. modified a comment on ticket #8

    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...

  • J.B. J.B. modified a comment on ticket #8

    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...

  • J.B. J.B. modified a comment on ticket #8

    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 H: 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...

  • J.B. J.B. posted a comment on ticket #8

    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 H: 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...

  • J.B. J.B. posted a comment on ticket #7

    Confirmed that http://altairclone.com/downloads/roms/DBL.ASM now assembles succesfully with a warning. I agree it may not be what most people want so a command-line switch is probably a good idea.

  • J.B. J.B. posted a comment on ticket #8

    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.

  • J.B. J.B. posted a comment on ticket #6

    I filed new bugs for the other problems.

  • J.B. J.B. created ticket #8

    Possible overflow bug in hex generator

  • J.B. J.B. created ticket #7

    Error when PC goes past FFFF

  • J.B. J.B. posted a comment on ticket #6

    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...

  • J.B. J.B. modified a comment on ticket #6

    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...

  • J.B. J.B. posted a comment on ticket #6

    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...

  • J.B. J.B. created ticket #6

    Problems with altmon.asm

  • J.B. J.B. modified a comment on discussion sidplay64 feedback

    I was hoping to study the source code to Sidplay64 and learn a few things but I looked...

  • J.B. J.B. posted a comment on discussion sidplay64 feedback

    Projects that are hosted on Sourceforge are required by their terms of service to...

1