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