CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[exxos]

I have fortified the ROM code in the PLD. I think part of the problem is that I am trying not to use CPU_AS in the ROM decoding, because I need to gain a few more nanoseconds speed for the ROM access. But the problem becomes that the address bus could be in a transition which could falsely trigger the ROM decoding circuit, where it would trigger the ROM chip and the DTACK state machine. But looking at the code, I had a delay line which could trigger DTACK on such transitions. So now DTACK only triggers when each of the delay lines is at exactly the same state. I guess it should have been like this to start with, but at least there is advantages of simply not looking at the code for a few months and then going back to it, and seeing potential problems

Anyway, below is 3 wait states on ROM versus 2 wait states on ROM.

3ws2ws.jpg (143.7 KiB) Viewed 3697 times

Now to add back in the blitter and watch chaos begin

[exxos]

Blitter back in... Working.. Though oddly we are running slower than the STE booster... I think this is part of the problem with running a external clock, as the synchronisation code takes some time. The timings are extremely tight on the STE booster which gives way to its speed despite its clock actually being slower than the SEC's 50MHz..

We can see with integer division a lot higher score over the STE. ROM access is 309% in both cases, RAM is 100% in both cases. I will try and tidying up the timings further, but I think we are already pushing it as it is...

x.jpg (168.46 KiB) Viewed 3686 times

EDIT:

So this time I put in ROM 1 wait state, ROM jumped to 344% (from 309%) and still scores are slower than STE.. bizzare...

1ws.jpg (66.5 KiB) Viewed 3682 times

Next I changed the RAM waitstates from 5WS to 4WS.. (ROM is still 1WS)

RAM is still 100%, ROM jumped up again and now is 368%.. and we still slower than the STE... Technically this should or not even be booting at these settings

1ws4ws.jpg (65.71 KiB) Viewed 3681 times

Next 3WS on RAM...

1ws3ws.jpg (59.03 KiB) Viewed 3680 times

Next 2WS on RAM and we get a funky flashing crash screen generator

[exxos]

As I was not convinced this was a firmware issue, I put in flashy clock to test TOS206 on the same machine with the blitter...

I thought it was odd that some tests were faster at 50 MHz than a STE, and then some tests were slower, it made no sense, so I basically tested my stock machine with TOS206 to compare against a STE with TOS206...

huh.jpg (72.67 KiB) Viewed 3668 times

So either my benchmark files are FUBAR.. or a STFM is inherently slower on some tests with a blitter than a STE
Taking into account the differences and compensating for my SEC results, they do actually work out as they should in that respect..

It will be useful if someone has a STFM with TOS206 (8MHz) who could compare it to a STE with TOS206 to confirm and verify my results above..


EDIT:

I recalibrated GB6 ( What a awesomely fantastic feature that is! ) on my STFM with blitter so all the scores started with 100%..

Now this is more like it is supposed to be... Some tests are still fractionally slower than the STE, but now the first test is 189% as opposed to the STE at 181%.

So the mystery remains as to why the STFM is slower with a blitter than the STE, but only on the VDI tests I can only currently assume there is some "bug" in the STFM GLUE chip or some issue in TOS206 itself which doesn't like a STFM.

rc.jpg (68.07 KiB) Viewed 3657 times

[exxos]

Started on a beta tester board for some lucky / unfortunate person Just adding in a slightly omitted pull-up resistor

1.jpg (121.23 KiB) Viewed 3627 times

EDIT:

So that board seems to be dead onto the next one then...

[exxos]

Got another board working Onto the next one now then Looks like some of these boosters have some bits missing Might be able to molish up about 5 in total, so good enough for beta testing

IMG_4790.JPG (412.2 KiB) Viewed 3595 times

[exxos]

Probably the worst benchmark ever, but this is basically the booster running at 8MHz. This was literally the first run without any code changes at all or anything, so it is actually really good that it boots up at all in this state. I now need to do a bit of tracing to see where in the code things are tripping up.. Though I think it is pretty clear it is on RAM access

As said ages ago, clock switching between unrelated clocks is a bit more complicated than synchronised clock switching I have been doing in the past. So I have been working on that circuits over the past couple of nights. Real-time switching should be able to be done via a software register.

I think it was @troed Who wanted this feature likely some years ago now But as everybody is sick of switches anyway..

slowwww.jpg (97.84 KiB) Viewed 3556 times

EDIT:

So this is extremely strange, I have changed my code that bypasses everything, and pretty much links ST_DTACK to CPU_DTACK, and RAM is still running at 50% speed. even turning the blitter of has no effect, so I think they should rule out bus grant stuff. Interrupts are all turned off during the tests. So I am not sure why this is running at half speed as it shouldn't be...

EDIT2:

So CUPL didn't like my variable SPEED_SEL for some reason.. It was like it was totally ignoring the signal and falling back to the 50MHz code So we back to 100% speed now

[exxos]

Clock switching code in.. Though its not behaving. Looks like its glitching somehow, but the simulation said it would work

The booster does run in 50MHz and 8MHz modes just fine though Just I am trying to fake a register change using CPU_AS etc like my old boosters do as I haven't got that far yet. But really the switch should work if done via a register. Will try and do that next..

NewFile0.png (9.76 KiB) Viewed 3532 times

NewFile1.png (8.43 KiB) Viewed 3532 times

NewFile2.png (8.39 KiB) Viewed 3532 times

[troed]

Yeah for me as a demo coder being able to run a boosted machine as stock dynamically through software, and then switch up the speed when compiling & linking, is exactly what's needed Being boosted all the time means not being able to use it at all when demo coding.

[exxos]

I'm just dumping this info here as will likely lose it , won't make any sense to anyone most likely, so just skip on ahead, nothing to see here

Measuring /AS(top) vs /WDAT(bottom) there is ~100ns delay between the 2. So likely 1x CLK8 cycle delay before /WDAT is issued.

AS_WDAT_100ns.png (100.78 KiB) Viewed 3734 times

From /DTACK(top) to /WDAT(bottom) there is ~20ns delay. ( I zoomed in later to verify)

DT_WDAT_20ns.png (106.91 KiB) Viewed 3734 times

From /AS (top) to /RDAT(bottom) there is ~75ns delay.. bizzare... Must be about 1 CLK16 cycle.

AS_RDAT_75.png (95.83 KiB) Viewed 3730 times

From DT (top) to /RDAT (bottom) 0ns delay...

DT_RDAT_0ns.png (98.15 KiB) Viewed 3729 times

EDIT:

I guess it could be that WDAT is based on the falling edge of CLK8, and RDAT is based on the rising edge of CLK8 I guess it would add a bit of delay on the buffers between read and write cycles to stop them shorting each other out.

EDIT2:


CLK8 vs RDAT - Goes low about the fall of CLK8

CLK8_RDAT.png (111.07 KiB) Viewed 3715 times

CLK8 vs WDAT - Glow low about the rise of CLK8

CLK8_WDAT.png (111.37 KiB) Viewed 3715 times

[PhilC]

Makes perfect sense to me