Recent Forum Posts
From categories:
page 1123...next »

Replying to my own post! :-) Seems I can't edit it.

Anyhow I was in error about the flashing address lines begining at 256… actually 128 . Still stumped. :-)

Amanda

Hi All! I just joined the site to hopefully gain some insight into the workings of the Z80. I'm hoping I can build a basic computer around the Z80.
To this point, I've bread-boarded a circuit to verify the CPU iis functioning properly. So far this seems to be the case.
The data lines are all tied low to effect a NOP instruction. All the address lines are driving LEDs through 74LS244 driver ICs.

However, there is something that puzzles me. The address lines count up normally to 65535, but when the count passes 255 any active line from A8 through A15 flashes. The flashing is the same frequency as M1, but opposite… M1 on, A8 - A15 off and vice versa.

I'm stumped. I've downloaded about a ream of documents on the Z80, but I'll be darned if I can see anything to unravel this. I've watched numerous videos about testing the CPU, but no one ever seems to monitor more than 4 or 5 address lines.
I suppose this is normal behavior for some reason given the limited setup I'm using.

Anyone have any thought on this? I'd be grateful!

Amanda - Have a great 4th!
(July 4th - alcohol and explosives. What could wrong?) :-)

Z80 Address Line Functioning by ajwardajward, 01 Jul 2017 18:16

new members!!! Well, that'd be me I guess! I just joined in the hope of learning more about the Z80.
I've started to explore the possibility of building a basic computer using the Z80. So far, I've built a tester to verify the CPU is functioning correctly and I "think" everything is okay. I'll have questions tho', but I'll address those in another area.

Happy to be here.

Amanda

Re: new members!!! by ajwardajward, 01 Jul 2017 17:34
Zilch (guest) 27 Jun 2017 03:59
in discussion Coding Forums / z80 programming » Read Back program memory

Older processors such as the Z80 did not have any onboard memory, so there is nothing to "read back".

If your system has EPROM (separate non-volatile memory chips, then the contents of these can easily be read out.

Zilch

by Zilch (guest), 27 Jun 2017 03:59

If you would like, you can add that to the end. It only applies to the eZ80, though (not the Z80).


Xeda96.pngXeda73.png
47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2

This could add a note that the contents of the B register are used as the upper byte of the port number for the (C) version, and the contents of A used as the upper byte for the fixed port version.

Could add the role of B by Piala AlicePiala Alice, 04 Jun 2017 18:38

On the newer models there is:

  • More RAM
  • More Flash
  • A different screen
  • An eZ80 processor

As a result, you'll need to use different graphics routines, and you'll need to use an updated list of addresses for built-in routines (which are now called instead of bcalled).

For the most part, the instruction set is backwards compatible (including an on-chip Z80 mode). However, instruction timings are different and with the introduction of new and more efficient instructions, many of the routines found here can be further optimized.

For the new system calls and addresses, you'll want to check out wikiti.


Xeda96.pngXeda73.png
47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2
Calculator Compatibility
Benjamin (guest) 25 Apr 2017 05:18
in discussion Coding Forums / z80 programming » Calculator Compatibility

I noticed in your basic tutorials on assembly programming that you often reference the TI-83 Plus in set-up downloads and programming but alternate paths for newer calculators are not clear. I was wondering how cross-compatible these tutorials were to newer calculators — especially the TI-84 CE — and what modifications if any were necessary to begin programming in assembly.

Calculator Compatibility by Benjamin (guest), 25 Apr 2017 05:18

Hi,

Firstly, I haven't looked at Z80 assembly since my childhood back in the late 80's. Whilst I'm quite competent in modern languages, Z80 assembly is something I've never revisited until I recently built a Z80-based single board computer. This runs a version of NASCOM BASIC, which is itself based on Microsoft BASIC from way back in '78.

Now I've got the computer up and running, I'm taking a break from building the next piece of hardware to add to it and instead focusing on the software for the moment. I'd like to make a few (relatively minor) changes to the BASIC interpreter running on the ROM, and in the process learn something about Z80 assembly etc.

What I'm currently trying to do is make the error messages a little more verbose. My first computer was an Amstrad CPC464, so naturally I'm trying to make the BASIC a little more like what I'm used to (already changed the OK prompt to READY.)

I'm hitting a problem with the error messages though. In its untouched form, the error messages are two-character bytes, like so:

ERRORS:     .BYTE   "NF"            ; NEXT without FOR
            .BYTE   "SN"            ; Syntax error
            .BYTE   "RG"            ; RETURN without GOSUB

Now the following lines of code handles printing a message:

ERROR:      CALL        CLREG           ; Clear registers and stack
            LD          (CTLOFG),A      ; Enable output (A is 0)
            CALL        STTLIN          ; Start new line
            LD          HL,ERRORS       ; Point to error codes
            LD          D,A             ; D = 0 (A is 0)
            LD          A,'?'
            CALL        OUTC            ; Output '?'
            ADD         HL,DE           ; Offset to correct error code
            LD          A,(HL)          ; First character
            CALL        OUTC            ; Output it
            CALL        GETCHR          ; Get next character
            CALL        OUTC            ; Output it
            LD          HL,ERRMSG       ; "Error" message
ERRIN:      CALL        PRS             ; Output message

Now initially (and somewhat naively) I thought I could just change the 2-character bytes in ERRORS: from, e.g. "SN" to "Syntax" - the word " Error" is added after each error message. I soon realised that this wasn't working, as there's a lookup table listing the location of each error message. Once I found that, all seemed to be roses for a while. I changed the code above so that instead of printing 2 characters and then moving on, it would loop through printing characters until it hit a 0.

; BASIC ERROR CODE VALUES

NF          .EQU    00H             ; NEXT without FOR
SN          .EQU    02H             ; Syntax error
RG          .EQU    04H             ; RETURN without GOSUB
OD          .EQU    06H             ; Out of DATA
FC          .EQU    08H             ; Function call error
OV          .EQU    0AH             ; Overflow
OM          .EQU    0CH             ; Out of memory

I added a zero to the end of each message in ERRORS: and changed the 2-char message to a more verbose one (so .BYTE "NF" became .BYTE "NEXT without FOR",0). I then amended the BASIC ERROR CODE VALUES lookup table (above) to take the length of the verbose error messages into account.

Everything was fine for the first few error messages. I'd tested the system and it worked. So I changed the rest of the error messages and updated the lookup table. Some of the values went as high as 124H etc, and I found I had to add a 0 to the lower offsets to avoid errors in TASM. However, I then started getting other errors - unused MS data errors in lines like LD E,(OS). I suspected this was because the offset was too large for a single 8-bit register like E, so where the errors came up I changed the code to LD DE,(<error msg offset label>) to make use of the full 16-bit DE register.

Obviously that didn't work - it stopped my ROM completely and locked the computer up. So, my long-winded question is winding to its conclusion - I don't currently know enough about assembly or the Z80 registers or the BASIC code I'm editing to know what I did wrong and why it was locking up the computer. I suspect this next bit of code is the culprit - taken from the message printing code further up:

LD          D,A             ; D = 0 (A is 0)
LD          A,'?'
CALL        OUTC            ; Output '?'
ADD         HL,DE           ; Offset to correct error code

If the error offset is loaded into E, then the first line above doesn't mess with it. But if, after I changed it to load into DE, D is then changed by the above code snippet, then the offset is going to be corrupted. Should I just remove the LD D,A line and the two after it as I'm not bothered about having the ? mark at the start of the error message either…

I honestly can't find anything. I know it's a pain, but you might have to find a more current compiler and port the code. It can't be that much different syntax. I hope it's not :/


Xeda96.pngXeda73.png
47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2
Re: Z80 compiler question by Xeda ElnaraXeda Elnara, 10 Mar 2017 18:00

The compiler I need is the Archimedes C ver3.1.

Does anyone know where I can get that version?

Thanks,

Doug

Re: Z80 compiler question by DB123DB123, 10 Mar 2017 17:41

I have some more clues.

The compiler command was "cz80 sourceFileName"
The linker command was "linkz80 sourceFileName"

Does that help identify the toolchain that was used originally in the real early 90's?

Doug

Re: Z80 compiler question by DB123DB123, 06 Mar 2017 15:42

Ooooh, yes. When you said 'compile assembly' I took that as an assembler XD um, I think small-C had a variant for the Z80 called Z88DK. Small-C is from the early 80s.


Xeda96.pngXeda73.png
47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2
Re: Z80 compiler question by Xeda ElnaraXeda Elnara, 06 Mar 2017 14:50

I went to: z80.info and downloaded the TASM V2.9 from March 92. It looks like TASM is for assembly code and not C code. I should have mentioned that the source code I have is C code. Did Borland support the Z80 processor in 93? Any idea what compilers for C code would have been available in 1993?

Thanks,
Doug

Re: Z80 compiler question by DB123DB123, 06 Mar 2017 14:47

I can't remember when TASM was released, but that is a likely candidate. I think Zilog's site has a list of assemblers. Sorry, I'm on mobile so it's a pain to verify.


Xeda96.pngXeda73.png
47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2
Re: Z80 compiler question by Xeda ElnaraXeda Elnara, 05 Mar 2017 21:57

I have piece of hardware with a functioning Z80 that was first created in in early 1993. I do have the source code but no documentation. Would anyone know how many compilers there would have been in 1993 for a PC that would compile Z80? I want to be able to compile this project and make some changes to it but I have no idea what it was created with.

Thanks,
Doug

Z80 compiler question by Doug B (guest), 05 Mar 2017 21:32

Does anyone know how to, or has anyone successfully retrieved the program memory from a Z80 or Z80A? I have one, and would like to retrieve the code from it, not sure if it's possible or not, but because it's an older chip, I'm assuming that the failsafes we have in today's newer processors are not there.

Read Back program memory by jediengineerjediengineer, 16 Feb 2017 15:31

Suppose you want an 8-bit counter, ideally in A:

    xor a    ;performs 'ld a,0', but does affect flags, which isn't a problem here.
loop:
        ;Do stuff, but return with A unchanged
        ;Probably requires 'push af \ do stuff \ pop af'
        ;or 'ld (var_A),a \ do stuff \ ld a,(var_A)'
    inc a
    cp 10
    jr nz,loop      ;use jp if the loop is too far
        ;loop is finished, so return or do whatever you were going to do.

If you need a 16-bit counter, ideally in HL, it is a similar process:
    ld hl,0
loop:
        ;Do stuff, but return with HL unchanged
        ;Probably requires 'push hl \ do stuff \ pop hl'
        ;or 'ld (var_HL),hl \ do stuff \ ld hl,(var_HL)'
    inc hl
    ;push de     ;use if you need to preserve DE
    ld de,10
    or a      ;\
    sbc hl,de ; |This essentially compares HL and DE.
    add hl,de ;/
    ;pop de      ;use if you need to preserve DE
    jr nz,loop   ;use 'jp' if the jump is too far.
        ;loop is finished, so return or do whatever you were going to do.

Xeda96.pngXeda73.png
47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2
John (guest) 17 Oct 2016 19:20
in discussion Coding Forums / z80 programming » incremental loop in Z80

Well, it has been about 35 years… but from memory…

When any subtract (including compare and decrement) operation takes the register to zero you get your zero flag set and then you can jump or jump relative based on that. But when you are going up to a specified valume then you are going to have to do an explicit compare each time.
If it is an 8 bit value then you need to compare ("cp") with the value which you are testing if you are going up to; the compare is actually a subrtact but it throws the result away, just leaving the flags. You have to do the compare against the accumulator ("a"). So while "a" is different (non-zero flag set) to the value being tested against "jr" (or "jp") to the top of the loop. I think there are also sign bits you can check with "jp" which you could achieve a "<" operation with (remeber you are subtracting the value you are testing against from the "a" register, so if the result is negative ("m" flag) then you have not got there yet); this would have to be a signed computation, so take care if your values are over 127.
Αre you dealing with a 16 bit value? If so that is particularly difficult. Because if it is a 16 bit value then there is NO 16 bit compare operation. You'd be doing this against the "hl" pair probably (or else it gets even more complicated) I think I would probably be tempted to push "hl", subtract the value to test against and then pop "hl" again (the pop shouldn't affect the flags) then "jr" or "jp" based on the flags. The alternative is to compare the "h" and the "l" registers seperately. Discussion of what to do with the flags is as above… Though you'll have to have a jp or jr after each 8bit test…..
Hm. why not keep it simple and work out how many bytes, then use "djnz"?
Incidentally, I just noticed the page instructions-set:jr has "jp" in several places it should have "jr", if someone wants to fix that.
Hope this all makes sense; please don't flame me if I got something wrong… I was a teenager when I did any of this last.

by John (guest), 17 Oct 2016 19:20
incremental loop in Z80
bruno (guest) 29 Sep 2016 20:41
in discussion Coding Forums / z80 programming » incremental loop in Z80

DJNZ can be used to test a counter and loop until it reaches 0, but is there an easy way to loop until a counter reaches a certain value? Like in the following C code:
for (int i=0; i<10;i++) {
// do something with i
}

Thank you.

incremental loop in Z80 by bruno (guest), 29 Sep 2016 20:41
page 1123...next »
Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.