[Coco] Frank Hogg Labs E-Forth, which is the only thing I’ve found that won’t run on the CoCo3FPGA ?
Dave Philipsen
dave at davebiz.com
Tue Feb 20 06:26:43 EST 2018
Interesting....
On 2/20/2018 4:25 AM, Leslie Ayling wrote:
> Hi Dave, Brett , et al.
>
>
>
>> I think Gary's implementation relies on the standard usage and does not account for different values in the data direction registers.
>
>
> True.
>
> From what I can see in the current version of CoCo3FPGA, the data register at $FF00 (KEYBOARD_IN) is always treated as an 8 bit *input* port regardless of the Data Direction bits.
>
> Likewise, the data register at $FF02 (KEY_COLUMN) is always treated as an 8 bit *output* port regardless of the Data Direction bits.
>
>
>
>
>
>
>
> Did a quick disassembly of the EFORTH.bin file.
>
>
>
>> I *think* the issue is that the program makes non-standard use of the keyboard PIA data ports.
>
>
> Not that I can see (so far).
>
>
>
> Appears to use $FF00 as normal inputs:
>
>
>
> RAM:3007
>
> RAM:3007
>
> RAM:3007 RESET_KBD: ; CODE XREF: sub_3838+6↓P
>
> RAM:3007 CC 30 34 ldd #$3034
>
> RAM:300A B7 FF 01 sta byte_FF01 ; $30 => FF01 = select DDRA, CA2 as output, CA2 -> Lo as MPU writes CRA
>
> RAM:300D 7F FF 00 clr byte_FF00 ; set A reg as all inputs
>
> RAM:3010 F7 FF 01 stb byte_FF01 ; $34 => FF01 = select RegA, CA2 as output, CA2 -> Lo as MPU writes CRA
>
> RAM:3013 39 rts
>
> RAM:3013 ; End of function RESET_KBD
>
>
>
>
>
> It does however, set up an interrupt handler on the CB1 input (*FS output of the 6847 chip == VBLANK more or less).
>
>
>
> RAM:2F05 INT_HANDLER: ; DATA XREF: RAM:2EF0↑o
>
> RAM:2F05 B6 FF 03 lda byte_FF03
>
> RAM:2F08 2A 1E bpl not_CB1_int ; branch if IRQA flag not set.
>
> RAM:2F0A B6 FF 02 lda byte_FF02 ; clear interrupt
>
> RAM:2F0D B6 09 85 lda byte_985
>
> RAM:2F10 27 0C beq loc_2F1E
>
> RAM:2F12 4A deca
>
> RAM:2F13 B7 09 85 sta byte_985
>
> RAM:2F16 26 06 bne loc_2F1E
>
> RAM:2F18 7F 2E E7 clr byte_2EE7
>
> RAM:2F1B 7F FF 40 clr FDC_CONTROL_REG
>
> RAM:2F1E
>
> RAM:2F1E loc_2F1E: ; CODE XREF: RAM:2F10↑j
>
> RAM:2F1E ; RAM:2F16↑j
>
> RAM:2F1E BE 00 8D ldx word_8D
>
> RAM:2F21 27 05 beq not_CB1_int
>
> RAM:2F23 30 1F leax -1,x
>
> RAM:2F25 BF 00 8D stx word_8D
>
> RAM:2F28
>
> RAM:2F28 not_CB1_int: ; CODE XREF: RAM:2F08↑j
>
> RAM:2F28 ; RAM:2F21↑j
>
> RAM:2F28 3B rti
>
>
>
>
>
> Code from CoCo3FPGA that provides the data available at $FF03:
>
>
>
> ===================================================================================
>
> // FF03, FF07, FF0B, FF0F, FF13, FF17, FF1B, FF1F
>
> ({ADDRESS[15:5], ADDRESS[1:0]} == 16'b1111111100011) ? {!VSYNC1_IRQ_BUF[1], 3'b011, SEL[1], DDR2, VSYNC1_POL, VSYNC1_IRQ_INT}:
>
>
>
> ….
>
>
>
> // V_SYNC int for COCO1
>
> // Output VSYNC1_IRQ_N
>
> // Status VSYNC1_IRQ_STAT_N
>
> // Buffer VSYNC1_IRQ_BUF
>
> // State VSYNC1_IRQ_SM
>
> // Input VSYNC_INT_N
>
> // Switch VSYNC1_IRQ_INT @ FF01
>
> // Polarity VSYNC1_POL
>
> // Clear FF02
>
> assign VSYNC1_CLK_N = VSYNC_INT_N ^ VSYNC1_POL;
>
> always @ (negedge PH_2 or negedge RESET_N)
>
> begin
>
> if(!RESET_N)
>
> begin
>
> VSYNC1_IRQ_BUF <= 2'b11;
>
> VSYNC1_IRQ_N <= 1'b1;
>
> end
>
> else
>
> begin
>
> VSYNC1_IRQ_BUF <= {VSYNC1_IRQ_BUF[0], VSYNC1_IRQ_STAT_N};
>
> VSYNC1_IRQ_N <= VSYNC1_IRQ_BUF[1] | !VSYNC1_IRQ_INT;
>
> end
>
> end
>
> always @ (negedge VSYNC1_CLK_N or negedge RST_FF02_N)
>
> begin
>
> if(!RST_FF02_N)
>
> begin
>
> VSYNC1_IRQ_STAT_N <= 1'b1; // no int
>
> end
>
> else
>
> begin
>
> VSYNC1_IRQ_STAT_N <= 1'b0; // Interrupt
>
> end
>
> end
>
>
>
> ====================================================================================
>
>
>
> Wonder if interrupt is being triggered correctly…
>
>
>
> More investigation required I think….
>
>
>
> Cheers,
>
> Leslie
>
>
>
>
>
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Brett Gordon
> Sent: Tuesday, 20 February 2018 1:15 AM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] ***SPAM*** Frank Hogg Labs E-Forth, which is the only thing I’ve found that won’t run on the CoCo3FPGA ?
>
>
>
> On Feb 19, 2018 9:06 AM, "Dave Philipsen" < <mailto:dave at davebiz.com> dave at davebiz.com> wrote:
>
>
>
> Hi Leslie. I think I downloaded this E-Forth package and tried it on the CoCo3FPGA. I *think* the issue is that the program makes non-standard use of the keyboard PIA data ports.
>
>
>
> Normally one port is configured as outputs while the other is configured as inputs. I think Gary's implementation relies on the standard usage and does not account for different values in the data direction registers.
>
>
>
>
>
>
>
>> I have had mixed result flipping ins for outs on real cocos too. I think its electrically hinky/dangerous also. So maybe we could flip the code around and turn any key tables by 90° and try again.
>
>
>
>
> As I recall, the program doesn't hang. You get an intro page but it doesn't correctly decode the keyboard.
>
>
>
>
>
> Dave
>
>
>
>
>
> On 2/19/2018 6:57 AM, Leslie Ayling wrote:
>
>
>
>> Hi Stephen, et al.
>> Just catching up on posts and saw this in your post.
>> Could you be more specific about what doesn't work in the E-Forth package?
>> Does it hang/not work at all etc.
>> Could you provide a link to the version you are using?
>> Cheers,
>> Leslie
>
More information about the Coco
mailing list