Intel 8080 Assembler Activity
Brought to you by:
jacotton
Activity for Intel 8080 Assembler
-
Jay Cotton posted a comment on ticket #10
Thanks for the catch. I'll have a go at it.
-
Daniel Snyder created ticket #10
Semi-colons in quoted text are seen as comments
-
extra tabs in listing file.
-
fix indent bug
-
I have a fix for this. but the gates are locked.
-
95 0140 C2 3D 01 jnz memset 96 0143 C9 ret 97 01 44 s171463 equ $ 98 0144 21 AC 04 lxi h,outfile 99 ;pzzp packfd "TEST.OUT" 100 01 47 pzzp equ $ 101 ; can't really see it with proportional spaceing ....
-
extra tabs in listing file.
-
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.
-
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...
-
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...
-
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...
-
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...
-
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 ;---------------------------------------------------------------...
-
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....
-
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.
-
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.
-
A resent bug was logged that seems a bit dicey to me. The asm file has near the end. 396 FFFE BUFFER: DW 00H ;FILLS THE EPROM OUT WITH 00'S 0000 *** Warning 17 in "dbl.asm": address wrapped at maxval 397 0000 DS 84H 398 399 ;--------------------------------------------------------------- 400 ; AND FINALLY THE STACK, WHICH GROWS DOWNWARD 401 ;--------------------------------------------------------------- 402 0085 STSP: DS 08H ;SPACE FOR STACK 403 00 8D STACK: EQU $ 404 405 END This seems inocent...
-
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.
-
Pushed a fix for this. What I did was break the code that prevents the wrap around. Did add a warning. Just in case you did not intent to wrap the address around. I my opinion the above is a bad fix. I may add a run time switch to allow users to decide they want broken behavior.
-
Fixes for pc address wrap around
-
I filed new bugs for the other problems.
-
Possible overflow bug in hex generator
-
Error when PC goes past FFFF
-
braceing like this ('I'+80h), gets around the problem.
-
The db '1'+80h looks like there is a missing call to eval. Will look at it more.
-
Did not see the hex file problem on altmon. But the hex dumper may have an overflow bug.
-
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...
-
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.
-
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.
-
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...
-
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...
-
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...
-
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...
-
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:...
-
Problems with altmon.asm
-
fix equ error
-
merge
-
fix major math bug
-
test update
-
fix signed multiply
-
correct and anotate test case
-
fixup logics
-
more bug fixing
-
added new bugs
-
fix a bunch of corner cases
-
fixed up test case
-
New test case from Jos
-
correct als8 to match Intel assembler syntax
-
gack, I can't type
-
fix typeo
-
added date and time to version
-
test files
-
log fix
-
Fix copyright
-
Update to current code base
-
Cleanup code base
-
Moving code to Mercurial
-
Moving to HG
-
initial commit
1