Program is in EEPROM (27C64) - I dumped it using a TL866 into a BIN file (have also the HEX)

(1) what de-assembler would you recomend me to get the code in assembler format ?

(2) is there any good "emulator" so I can feed the BIN and execute instructions one by one, see the register, the memory, etc ?

Thanks. Ramon.

"If you use push hl, first the value of SP is decremented by two, then virtually an ld (sp),hl happens".

Just a note on the PUSH descriptions - shouldn't it say the stack pointer is DEcremented by 2 bytes?

just those which i tested.

i joined wikidot and applied for membership in Z80-heaven to corret it.
yesterday i had the impression i could edit the page but today i seem to be no longer a member of Z80-heaven.

links to this wiki can only be placed with a big warning ahead. :-(

New member here, An old Trs-80 user from 1979 and more recently an N8VEM and S100 DIYer.

Interested in TRS-80 Graphics programming and generally messing around.

Having fun with the Oshon Z80 Simulator IDE!

From the Zilog Z80 manual:

Operation
(SP – 2) ← qqL, (SP – 1) ← qqH

Description
The contents of the register pair qq are pushed to the external memory last-in, first-out
(LIFO) stack. The Stack Pointer (SP) Register pair holds the 16-bit address of the current
top of the Stack. This instruction first decrements SP and loads the high-order byte of register
pair qq to the memory address specified by the SP. The SP is decremented again and
loads the low-order byte of qq to the memory location corresponding to this new address
in the SP. The operand qq identifies register pair BC, DE, HL, or AF, assembled as follows
in the object code:

Note that LD (HL),n does appear on opcode reference chart [url]/opcode-reference-chart[/url].
Source: pp211-214 Z80 Reference Guide; ISBN 0-86161-162-4; 1984 Melbourne House Publishers; Alan Tully Author

Real noodles don't try to rule the waves.

.nolist #include "ti83plus.inc" .org userMem-2 .db $BB,$6D .list bcall(_RclAns) bcall(_ConvOp1) ld a,e or a jr z,Install_Interrupt dec a ret nz Uninstall_Interrupt: im 1 ret Install_Interrupt: di ld hl,$9900 ld de,$9901 ld bc,256 ld (hl),$9a ldir ld hl,interrupt_start ld de,$9a9a ld bc,interrupt_end-interrupt_start ldir ld a,$99 ld i,a im 2 ;switch to mode 2 ei ;enable interrupts ret Interrupt_Start: ex af,af' exx in a,($03) and %11111110 out ($03),a call $003A reti Interrupt_End: .end

Edit: For the most part, complete.

This page is in need of an overhaul and while I want to keep the cheeky language, it's absolutely incorrect about a few key points. Application headers are restricted to 128 bytes, but only as an upper limit. A minimum header is a few dozen bytes. An example here is 32 bytes and could be less depending on the size of the app name.:

.org $4000 .db $80,$0F, 0,0,0,0 .db $80,$12, $01,$04 ;signing key ID .db $80,$47, "AppName" ;change the $47 according to name len (last nibble is the length). .db $80,$81, 1 ;num pages .db $80,$90 ;no splash .db $03,$22,$09,$00 ;date stamp .db $02,$00 ;date stamp signature .db $80,$70 ;final field appstart:

I must have been practically a heathen when I made these routines XD

I have better algorithms and faster codes, comment if you need something or if I forget to edit.

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

Amanda

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?) :-)

Happy to be here.

Amanda

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

Zilch

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

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…

Does anyone know where I can get that version?

Thanks,

Doug

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

Thanks,
Doug

Thanks,
Doug

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.

Thank you.

It's not possible to say what this code fragment does because there is no context and you have given no information about it.
As pure code it's very straight forward but meaningless on it's own.

You mentioned it is to do with a game and about finding a place in France. So my best guess is that this is a patch file to add or change that feature in the game.

You should try and contact the game creators or a game players forum to find out what to do with it. Hope that helps :-)

So what I was wondering was if there were any disadvantages/advantages when it comes to LD DE,(xxxx) and LD HL,(xxxx) / EX HL,DE

I've used:

LD HL,(xxxx)
EX HL,DE

to get my Data into the DE register first, followed by getting the Data HL requires last, which saves using LD DE,(xxxx). At the end of it all it appears the same amount of opcodes are used as well as clock cycles, but was wondering if anyone knows any different?

Likewise with CPDR