After about 50 hours of experimenting I finally got it to run!!
I had a lot of ideas to work through it seems the problem lies in AVEC being triggered twice during a VPA cycle.
I was using VMA as a delay start of the AVEC cycle but also added in a chain of delays which would basically only allow AVEC to trigger once.. But the some odd reason the floppy drive light would come on and I would just end up with a white screen..
Then I had an idea as I was using VMA, simulated based on E-clock, I thought I would just reset the E-clock FF's like this...
Code: Select all
QA.AR = !RESET # CPU_AS;
QB.AR = !RESET # CPU_AS;
QC.AR = !RESET # CPU_AS;
QD.AR = !RESET # CPU_AS;
And shockingly this seems to have solved the problem... Now I just have to really work out exactly why
It could also be ACIA is still holding data on the bus while the CPU is trying to do something else, so clearing E-clock likely disable the ACIA.. So a few things yet to investigate..
- yay.jpg (138.59 KiB) Viewed 4423 times
Of course the scores are pretty messed up, but this is due to very slow delay lines while I was debugging.. But we can see on integer division that the CPU is running at 32MHz.. But most importantly it actually worked!!
Now I need a beer!
EDIT:
So some more testing, the VMA delay chain was removed from AVEC and set with 2x!CLK8 instead and this to test OK.. So next up I ran E,VMA at double speed (16MHz) and this did seem to partly work but was unstable and crashed after the first test.. So we could be hinting that there is a bus conflict right after the AVEC cycle likely with the ACIA chips.
EDIT2:
Code: Select all
!AVEC.CK = !CLK8;
!AVEC.D = AV1 & ST_DTACK & !CPU_AS;
AV1.CK = !CLK8;
AV1.D = FC2 & FC1 & FC0 & !VPA & A19 & A18 & A17 & A16 ;
Added in ST_DTACK & CPU_AS to AVEC.... Now it seems to be running stable now..
So possible there are two problems.. ACIA causing bus conflict due to being driven from the 8MHz.. And also re-triggering of AVEC..
Now to do some soak testing