• Please review our updated Terms and Rules here

Figuring out serial port address and memory map on obscure system?

C

Christoffer

Experienced Member
Joined
Oct 15, 2014
Messages
299
Location
Denmark
Hi! so, i'm currently messing around with a small "ECB" z-80 computer i bought. I think it's a swedish traffic data controller from the 80's, from the ascii strings i can see in ROM.

The CPU card is a true SBC, with 4K rom, some SRAM, Z80 CPU, Z80 SIO/2, and Z80 CTC (that also sets baudrate).
it boots, then stays on boot message forever. If a key is held down during boot, or if the accompanying RAM/ROM card isn't inserted it goes to a monitor style promt or debugger where you can edit memory, see registers and run from address etc. it has a few options i've no idea what does too.

All the boards look non-specific built, so it SHOULD be possible to get it running other stuff (BASIC, CP/M even.), but there's one problem: A lot of the decode is done in 82S131 PROMS which I can't read, so I can't directly find the address for the UART and CTC hardware wise.

Also, the RAM/ROM card has a full 64K SRAM/EPROM mix, so the CPU card MUST be able to switch between memory on card/memory on bus. This could be a flipflop set via an IO address too i suppose.

Question is how do I figure these hidden addresses out? My plan was to look at the small 2K roms on the CPU card, since these must have routines for serial, and so the hardware addresses should be declared somewhere presumably in the start of the code, i'm just not smart enough to decipher disassembled code.

Here's the first bits of code, and the first use of "OUT", which I assume is what i'm looking for.. Any ideas?
Code: 
				;
				;	Disassembled by:
				;		DASMx object code disassembler
				;		(c) Copyright 1996-2003   Conquest Consultants
				;		Version 1.40 (Oct 18 2003)
				;
				;	File:		DADACmout.bin
				;
				;	Size:		2048 bytes
				;	Checksum:	D5EB
				;	CRC-32:		9BCF39D4
				;
				;	Date:		Sun Jun 03 20:04:13 2018
				;
				;	CPU:		Zilog Z80 (Z80 family)
				;
				;
				;
					org	00000H
				;
0000				L0000:
0000 : 18 08		"  "		jr	L000A
0002 : C3 97 00		"   "		jp	L0097
0005 : 18 F9		"  "		jr	L0000
0007 : C3 4B 01		" K "		jp	L014B
				;
000A				L000A:
000A : 31 00 13		"1  "		ld	sp,01300H
000D : 21 00 10		"!  "		ld	hl,01000H
0010 : 11 01 10		"   "		ld	de,01001H
0013 : 01 FF 02		"   "		ld	bc,002FFH
0016 : 36 00		"6 "		ld	(hl),000H
0018 : ED B0		"  "		ldir
001A : 3E 12		"> "		ld	a,012H
001C : ED 47		" G"		ld	i,a
001E : ED 5E		" ^"		im	2
0020 : 21 07 05		"!  "		ld	hl,00507H
0023 : 22 F4 11		""  "		ld	(X11F4),hl
0026 : 7D		"}"		ld	a,l
0027 : 21 06 01		"!  "		ld	hl,00106H
002A : 18 10		"  "		jr	L003C
				;
002C : 00		" "		nop
002D : 00		" "		nop
002E : 00		" "		nop
002F : 00		" "		nop
0030 : 00		" "		nop
0031 : 00		" "		nop
0032 : 00		" "		nop
0033 : 00		" "		nop
0034 : 00		" "		nop
0035 : 00		" "		nop
0036 : 00		" "		nop
0037 : 00		" "		nop
0038				L0038:
0038 : F3		" "		di
0039 : C3 F1 05		"   "		jp	L05F1
				;
003C				L003C:
003C : 11 00 12		"   "		ld	de,01200H
003F : 01 20 00		"   "		ld	bc,00020H
0042 : ED B0		"  "		ldir
0044 : 21 D4 00		"!  "		ld	hl,000D4H
0047 : CD C9 00		"   "		call	L00C9
004A : E5		" "		push	hl
004B : 21 00 11		"!  "		ld	hl,X1100
004E : 97		" "		sub	a
004F : 77		"w"		ld	(hl),a
0050 : CD C3 00		"   "		call	L00C3
0053 : 3E 30		">0"		ld	a,030H
0055 : ED 79		" y"		out	(c),a
0057 : 18 11		"  "		jr	L006A


Thanks in advance!

oh, and here's a few pics of the boards.

The CPU card seems to be from JET computers AB, memory from "Metric"..

cpu.jpg
mem.jpg
 
Do you know if the peripherals are I/O port or memory-mapped?

While you could iterate through I/O or memory addresses looking for distinctive patterns in response to a read or input, you could also perform the same iteration using a line from the appropriate chip's "select" line and wire it to the TRAP line. The trap ISR should give you a pretty good indication of where the chip is located.

On the other hand, if you know that the chips are I/O mapped, there are only 256 I/O addresses. So you could scan until you hit something that wasn't an 0xff or 0x00 and then hit that address repeatedly (using an IN instruction) and see which chip is selected using your logic probe.
 
I'm assuming they're IO mapped. that's an easy check with a logic probe though, if it triggers IORQ at all it probably does so consistently.

The Z-80 doesn't really have a TRAP like the 8085 does, unfortunately. could I wire the individual chip's select line (/CS) to the Z80 /WAIT, and then just read off the data bus?
 
Ah, okay, yeah i get they work the same, but wouldn't triggering /WAIT keep the address on the address bus and let me read it off too? I'm not sure how i'd access the Z80's ISR after trapping with no I/O capabilities.
 
alright! did just that, and the address was frozen at 00000111b ! since A0+1 is directly wired to the registers that'd give the chip a base address of 100b as far as i can see.

And doing the same for the baud CTC chip gives 0000010b - this makes sense because then the two chips are mapped right next to each other: CTC 00H-03H; SIO 04H-07H
 
Last edited:
Wow, that took a headache or two! I've partially reverse engineered the CPU card to gain insight in how it works with the memory bank switching, and here's what I came up with..

It It looks to me like a certain address A2-A7 triggers the bus /WRITE EN signal, that i think here is used to switch banks, as it shifts bit 7 of the data bus into a flip flop that controls the addressing of the on-board ram/rom. I'll try the /WAIT trick with the address enable signal and figure that out if i can aand i guess that was all the mysteries this board held! I'm sorta pleased with that outcome.

ECB M-CPU-S.jpg
 
If the 82S131 don't have any security then I have a programmer than can read them if that is any use. If you wanted to cover the post/freight to and from Australia I could give you the binary files. I'm not sure, but PROMs that are that early probably didn't have security.
 
Sleepwalker3 said:
PROMs that are that early probably didn't have security.
Click to expand...

stand-alone proms CAN'T have security by the nature of their design.

internal proms in microcontrollers can, and mostly did as a security measure against reverse-engineering after the first generation or so of parts

early PLAs, like the 82S100 and 105 also were not protected
 
Sleepwalker3: Thanks! I might take you up on you offer eventually, but I think i've figured out enough to get it going.

What I might do is disable the CPU board memory entirely and have it boot directly from the big memory card. It seems to have the same basic setup as the AMPRO littleboard -floppy interface, but copying the ampro circuit for that WD1772 floppy controller should be doable. the int/ext memory flipflop can just be forced hi or lo by removing the chip from the socket and jumping Q to either VCC or GND.

I'm not too familiar with the littleboard circuits yet, but aren't they fairly straightforward? O'm gonna use sram instead of DRAM, but aside from that, if i edit IO addresses in ROM, i think it's viable.

Does anyone know the diff. between the z80 littleboard boot rom and monitor rom?

thanks!
 
Al Kossow said:
stand-alone proms CAN'T have security by the nature of their design.

internal proms in microcontrollers can, and mostly did as a security measure against reverse-engineering after the first generation or so of parts

early PLAs, like the 82S100 and 105 also were not protected
Click to expand...

I don't imaging an address decoder would even work with some kind of security. After all, it is suppose to decode addresses on the fly. I could imaging one might require two addresses in sequence to unlock it but more than that I can't imagine much more. It could have a watchdog like function, causing the processor to reset if it got to an undefined address. This might be desired for something like a signal light but still that is a function of the overall circuit and not the security of the decoder itself.
Dwight
 
You must log in or register to reply here.
Back
Top