ROM Request: Altos ACS 8000 models with 8000 or 8100 logic board
Jay Jaeger
cube1 at charter.net
Sat Jul 11 21:46:56 CDT 2015
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
>
More information about the cctech
mailing list