Jmstein7 wrote:
Yeah, I can see - I've been looking at your vhdl version in your BeebFpga directory. I tried to work that one in, but that doesn't work, either. But, I can see you've really done a LOT of work on that core. Even though you didn't create the initial version, the more refined product is clearly yours. If only it would work, here
I've lost track slightly of where you are up to....
Have you managed to build/run the version in my fork that uses cpu_clken (with the VHDL version of the ACIA)?
I'm running that version and it's working pretty well on real hardware for me.
I'm using a 50MHz oscillator as the system clock, because that's what's on my FPGA board.
I've tried various values of the clken counter:
- 2 bits gives an effective CPU rate of 12.5MHz
- 4 bits gives an effective CPU rate of 3.125MHz
- 6 bits gives an effective CPU rate of 0.78125MHz
I've also run the system clock at 4MHz (by hacking in a DCM to convert from 50MHz to 4MHz), and with a 2-bit clken counter this gives an effective CPU rate of 1MHz.
The system runs in all of these cases, but I'm getting some dropped characters on the serial output.
I've noticed there is a fixed delay loop at $EF00:
Code:
Sef00 phx
phy
ldy #$8f
Lef04 ldx #$05
Lef06 dex
bne Lef06
dey
bne Lef04
ply
plx
rts
This delay is added after each character is printed. It consumes 5,576 65C02 cycles, which is quite a lot (5.5ms @ 1MHz).
If I bypass that loop, by placing an RTS at $ef00, the dropped characters go away, and I can dump the whole of memory without any issues. I don't understand why the delay would cause dropped characters on output. I suspect the real issue is a synchronization bug in the ACIA, and getting rid of the delay loop somehow masks this bug.
Dave
Login
Register
FAQ
Search
It's okay, though - that's just makes it all the more sweeter when we solve it 
