13 Jul
2015
13 Jul
'15
2:40 a.m.
Further update. The Z80-A CTC appears to be the culprit. The logic
analyzer told me that INT# was being asserted (active low) right out of
the gate. Removal of the chips that connect to INT# and inserting them
one at a time until the symptom re-appeared revealed the CTC chip as
having a problem. And, if I bend the interrupt pin on the CTC out, the
ROM program proceeds further. The ROM code gets past the point where
the "%" should appears on the console - but it still does not appear.
But I figure that if the CTC is bad, it is not at all unlikely that the
clock going over to the SIO chip is wrong or even nonexistant. Plus, a
later chunk of code loops forever waiting for transmitter buffer empty
from the SIO chip. (Check that tomorrow).
On 7/11/2015 9:46 PM, Jay Jaeger wrote:
An update: Although I still expect there is an issue
with that loop
count of 10 (0x0A), I went ahead and stuck my logic analyzer on it in
state mode just to see what, if anything, was going on.
The CPU is running and runs the program in the ROM as expected at first.
But the program gets to the point of location 0x13, and then goes awry.
Noticing that is just after interrupts are enabled, I suspect it is
taking an interrupt at a location it isn't expecting: in particular, it
seems to be vectoring through location 0, which of course was not
intended to be an interrupt vector. So, the CPU ends up fetching the
next instruction from address 0x5EED, which is a 0xFF - uninitialized
RAM, actually - which to a Z80 is a rst 0x38 - which is where the
program picks up again.
So, either it should not be interrupting, or whatever is interrupting is
not placing the correct 8 bits of the interrupt vector there for the
CPU, so it ends up in the wrong place.
But, at least I have something to go on.
JRJ
On 7/11/2015 2:26 PM, Jay Jaeger wrote:
In working on my ACS 8000-2, I managed to dump
the ROM and started
disassembling it, and almost immediately came up with something strange
(see below). As a result, it is not surprising the machine is totally
confused.
If anyone has an Altos ACS 8000, models 1 thru 4 or 1S thru 4S, that is,
an Altos 8000 with an 8000 or 8100 circuit board, I would really
appreciate a dump of the ROM, as mine either has a coding error (in
which case there could be more) or a bit pick (in which case there could
be more) or some kind of flat-out bug.
Even a paper listing would be just fine. I have at least two different
ways I ought to be able to program a 2708 if I need to (and I almost
certainly do).
Below is what I found, right at the start of my ROM. The oddness is
that the Stack Pointer, which is used to do pop values into BC for the
port and byte count for a series of OTIR commands is initialized by the
code to point at 0x35E. Data for these commands starts at 036E. The
iteration count for the overall loop is 0x0A (10 decimal).
Here is the problem: given where the stack starts, 0x35E, that is used
to pop successive port/bytecount pairs into BC, there is only room for 8
of them before it gets to 0x36E, and the data there is clearly NOT part
of the port/bytecount pairs pattern.
So, it seems that one of the following is true:
- The iteration count has a bit pick and should be 08 instead of 0A
- The starting stack pointer has a bit pick, and should be
0x35A instead of 0x35E
- There is a coding error (essentially equivalent to the first choice)
There is some evidence to support any of these possible choices, though
right now it seems most likely that the iteration count of 0x0A really
should be 0x08. If someone has a known good ACS 8000 ROM image, then I
could sort it out more easily.
Anyway, given this, it is no wonder the machine is getting confused.
Thanks in advance.
JRJ
Input file: test.bin
0000 ED5E im 2 ; Set Interrupt Mode 2
;
; Initialization outputs
;
; Port 0A 5 bytes (PIO Y2 Channel A)
; Port 0B 5 bytes (PIO Y2 Channel B)
; Port 12 5 bytes (PIO Y4 Channel A)
; port 13 2 bytes (PIO Y4 Channel B)
; port 0C 3 bytes (Console Baud Rate, Y3 CTC CH0)
; port 0E 2 bytes (Printer Baud Rate, JX CTC CH2)
; port 1D 6 bytes (SIO Channel A - Console - Y7)
; port 1F 6 bytes (SIO Channel B - Printer - Y7)
;
0002 216E03 ld hl,0x036E ; HL <- 0x36E
0005 315E03 ld sp,0x035E ; SP <- 0x35E
0008 160A ld d,0x0A ; D <- 0x0A
000A C1 pop bc ; BC <- (SP)
000B EDB3 otir ; Output, as described above
;
; In "peudo C", the otir instruction would do:
;
; do {
; output(C,*HL++);
; } until(--B == 0);
;
000D 15 dec d ; Total iterations, 0x0A (10) times
000E 20FA jr nz,0x000A
;
; Done with initializations
;
0010 FB ei ; Turn on interrupts
0011 31FF3F ld sp,0x3FFF ; Real SP initialization
; for RAM during boot,
; Bit 10 MUST be a '1'
0014 3E00 ld a,0x00 ; A <- 0
... Left out the rest of the disassembly
0357 FB ei
0358 ED4D reti
;
; Data appears to begin here.
;
035A 04 inc b
035B 08 ex af,af'
035C 1020 djnz 0x037E
035E 0A ld a,(bc)
035F 05 dec b
0360 0B dec bc
0361 05 dec b
0362 12 ld (de),a
0363 05 dec b
0364 13 inc de
0365 02 ld (bc),a
0366 0C inc c
0367 03 inc bc
0368 0E02 ld c,0x02
036A 1D dec e
036B 061F ld b,0x1F
036D 06CF ld b,0xCF
036F 42 ld b,d
0370 5E ld e,(hl)
0371 37 scf
0372 BF cp a
0373 CF rst 0x08
0374 FC6A37 call m,0x376A
0377 FECF cp 0xCF
0379 F8 ret m
037A 6C ld l,h
037B 37 scf
037C DF rst 0x18
037D 0F rrca
037E 03 inc bc
037F 47 ld b,a
0380 0D dec c
0381 60 ld h,b
0382 07 rlca
0383 34 inc (hl)
0384 04 inc b
0385 44 ld b,h
0386 03 inc bc
0387 E1 pop hl
0388 05 dec b
0389 EA0444 jp pe,0x4404
038C 03 inc bc
038D E1 pop hl
038E 05 dec b
038F EA3031 jp pe,0x3130