exxos's Atari, Amiga & retro forum

Icky wrote: 12 Nov 2019 21:14 Just trying to figure out how to sort out the CLK_EN_p and CLK_EN_n what with that and the distraction of almost getting my printer to do a first ever print this evening :)

Here's an example in ijor's FX68K how to create the two clock enables (it's for 32MHz, so divides by 4, but easy to convert to 16MHz/2):
https://github.com/ijor/fx68k/blob/mast ... k.sv#L2648

slingshot wrote: 12 Nov 2019 21:56

Icky wrote: 12 Nov 2019 21:14 Just trying to figure out how to sort out the CLK_EN_p and CLK_EN_n what with that and the distraction of almost getting my printer to do a first ever print this evening :)

Here's an example in ijor's FX68K how to create the two clock enables (it's for 32MHz, so divides by 4, but easy to convert to 16MHz/2):
https://github.com/ijor/fx68k/blob/mast ... k.sv#L2648

Thanks. I had just been looking at that file trying to find an example. Let's see if I can get this working on the board, if I don't get interrupted by non-Atari stuff.

Got slingshots changes to compile last night but it was 1 am in the morning too late to start testing. Will look at plugging the Sparklaphobia (FPGA Blitter) board in to test tonight after normal non-Atari day life is out of the way.

slingshot wrote: 12 Nov 2019 21:52 That's why I'm interested in the re-creation from the schematics.

Exxos and I are still going to continue with the schematics re-creation as that’s going to be a good base to start with.

slingshot wrote: 12 Nov 2019 21:52

Cyprian wrote: 12 Nov 2019 20:52 "Release the bus for 64 CLK cycles." - it uses wrong cycle split scheme

I've also changed that back to 64/64.

I don't know how the original performs, but my main interest is demo compatibility, which require cycle perfect operation, and it's hard to achieve without having this as a design goal from the beginning. That's why I'm interested in the re-creation from the schematics.

the split on the real hardware looks like:
- 65 bus cycles for the BLiTTER - 63 for fetching data plus 2 for bus mastering;
- 64 bus cycles for the CPU. One important remark. The BLiTTER counts 64 cycles USED by the CPU. It means long instructions (like div) can significantly delay the BLiTTER.

That split is implemented in the latest Hatari and Steem emulators since this year.

If I'm not wrong, in the Suska's code I see that wrong 64/64 split scheme, and also I can't see code responsible for counting cycles used by the CPU.

Cyprian wrote: 13 Nov 2019 09:40
If I'm not wrong, in the Suska's code I see that wrong 64/64 split scheme, and also I can't see code responsible for counting cycles used by the CPU.

On the schematics, it can be seen that the HOG counter counts the XASI signal (incoming AS when the CPU is the bus master, outgoing when the Blitter is), that's how many times the CPU/Blitter accesses the memory. Yeah, it's not implemented this way in Suska. But that's not the only difference from the original behavior.
And that's another example why it's risky to implement this 1:1 in FPGA: here the internal AS signal is a _clock_. Not a good idea for an FPGA.

slingshot wrote: 13 Nov 2019 10:40On the schematics, it can be seen that the HOG counter counts the XASI signal (incoming AS when the CPU is the bus master, outgoing when the Blitter is), that's how many times the CPU/Blitter accesses the memory. Yeah, it's not implemented this way in Suska.

I spent so many hours to find a bug in my blitter code, which finally appeared that CPU access counting.
Would be better to learn read schematics before :)

slingshot wrote: 13 Nov 2019 10:40But that's not the only difference from the original behavior.
And that's another example why it's risky to implement this 1:1 in FPGA: here the internal AS signal is a _clock_. Not a good idea for an FPGA.

interesting.

Cyprian wrote: 13 Nov 2019 11:41

slingshot wrote: 13 Nov 2019 10:40On the schematics, it can be seen that the HOG counter counts the XASI signal (incoming AS when the CPU is the bus master, outgoing when the Blitter is), that's how many times the CPU/Blitter accesses the memory. Yeah, it's not implemented this way in Suska.

I spent so many hours to find a bug in my blitter code, which finally appeared that CPU access counting.
Would be better to learn read schematics before :)

What did you try to do and what was the consequence of this? How did this "bug" present itself? I'm interested as I'm messing with the Blitter quiet a lot lately.

Thanks,
Daniel

Cyprian wrote: 13 Nov 2019 11:41
I spent so many hours to find a bug in my blitter code, which finally appeared that CPU access counting.

I will change the code to count AS edges instead of pure clock ticks. Maybe it'll fix everything magically :) (Well, don't think so, but probably will better).

dhedberg wrote: 13 Nov 2019 11:59 What did you try to do and what was the consequence of this? How did this "bug" present itself? I'm interested as I'm messing with the Blitter quiet a lot lately.

Thanks,
Daniel

Below you can find a graphics representation of that behaviour. That screenshot is taken from real hardware.
White/grey/red stripes are the CPU activity, a black one is the BLiTTER.
1) In case of famous "64/64" bus cycle split, there should be black rectangle through whole screen.
On the real hardware the BLiTTER part is skewed (65/64)- we can see that on my screenshot - just below numbers, a first few scanlines have skewed black lines.

2) Some instructions can delay the BLiTTER.
In my case black lines (the BLiTTER part) are separated by white ones ("DIVS" instruction).


more you can find there:
http://www.atari-forum.com/viewtopic.ph ... 25#p313292
http://www.atari-forum.com/viewtopic.ph ... 25#p228964

And another one with parallel running the BLiTTER and the CPU
http://www.atari-forum.com/viewtopic.php?p=96197#p96197