CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[PhilC]

Cool, made some good progress the last few days

[exxos]

So things are working at 40MHz basically fine now. Though I still have the original problem where TOS206 doesn't work at 50MHz. But TOS104 & EMUTOS do.

How it basically seems,TOS206 has some "bug" preventing it booting up at 50MHz. TOS104 has some "bug" preventing the floppy from being formatted without a initial error. 40MHz works fine TOS104 & TOS206 (basically) but I can't fix TOS206 from not booting at 50MHz.

I have tried many times to slow down ROM access on 206 to see if I can get it to boot, but it just isn't happy.. I will try some more, but how its looking, TOS206 just isn't going to work at 50MHz Basically we have hit the limits of the OS itself so its looking like only EMUTOS is going to be stable at 50MHz.

[exxos]

I went back to what Troed posted about the start-up sequence..

https://www.exxosforum.co.uk/forum/viewt ... tup#p10101


Looks like right from the start the diagnostic cartridge is checked for.. But I am not even getting that for it seems..

Oddly though on power up I do see a lot of activity on /AS and periodically see ROM_CE switching.. But it looks like the same pattern over and over for about 10 seconds until it dies totally..

Very odd...

[exxos]

supaduper Kindly soldered the CPU and PLD onto the Rev2 board for me! Super job for sure! So hopefully I won't have to spend ages fighting my iffy soldering on these boards.

This board I had to solder the SND_CS wire onto a spare PLD pin... I've soldered up the rest of the board.. so now to work on the firmware.. its almost the same as the V1, but a few more signals are routed via the PLD, and a few pins moved about.. But hopefully won't take long to get this firmware going..

rv.jpg (177.02 KiB) Viewed 4245 times

IMG_3791.JPG (435.99 KiB) Viewed 4241 times

EDIT:

Firmware patched over and now running 40MHz as before Now to see if I can figure anything out with TOS206...

[ijor]

TOS104 has some "bug" preventing the floppy from being formatted without a initial error.

ST TOS uses a software loop to detect timeout on floppy operations. IIRC the loop will timeout in something like a second a half. That is, of course, assuming a stock CPU running at ~8MHz. Formatting a track is the slowest FDC command. It takes between one and two revolutions depending the exact position of the index hole. Two revolutions is close to half a second (400 ms).

I m too lazy to perform the full math. And the exact timing depends on your exact PLD code because part of the loop reads the MFP and then one bus cycle of the loop would run slow. But making an estimate is not surprising that a 50 MHZ CPU would sometimes timeout when formatting a track.

IIRC this was fixed in STE TOS already (certainly in TOS 2.x) to use the 200 Hz hardware timer, instead of a software loop, for detecting a timeout.

TOS 1.0 would probably be even worse. But I guess you don't care.

[exxos]

In relation to TOS206 not booting at 50MHz..

I contacted Thorsten Otto who posted the startup code for TOS104 and TOS206 and its identical. So I am thinking more towards some noise on some addressline which only effects TOS206 not TOS104, as that is the only difference.

E00000 - EFFFFF
1110 0000 0000 0000 0000 0000
1110 1111 1111 1111 1111 1111

FC0000 - FEFFFF
1111 1100 0000 0000 0000 0000
1111 1110 1111 1111 1111 1111


The only difference is at the start.

111X Where A20 is low on 104 space and high on 206 space. The thought here would be A20 would have enough noise to appear low when TOS206 is booting. Its unlikely, but its the only idea I have. I mean TOS206 boots 40MHz, not 50MHz, so something is unhappy...

Problem also is I even slowed down ROM access to stock speeds and 206 didn't boot at 50MHz. So its unlikely to be noise. But there is no difference in the startup of TOS other than the address range TOS itself uses. So it has to be that..

[exxos]

After a rest all weekend, I came back to investigate the TOS206 50MHz issue and now have it working!

20650.jpg (93.18 KiB) Viewed 4160 times

I went around with the scope on each ROM pin, usual chaos, nothing to bad. So then I went around with 390pF on each pin and it booted up every time with the cap on A1! Bizzare.. But maybe a clue as its also linked to the DMA!

With cap..

cap1.png (6.72 KiB) Viewed 4160 times

without cap..

cap0.png (6.75 KiB) Viewed 4160 times

Not really any difference. Though I may route A1 via the PLD to buffer it and have the option to add some delays on there.. need to do more testing...


EDIT:

I guess its possible there is some glitch somewhere which I don't see. Though its possible there are some slight timings issues with slow clock edges and delays in the GLUE logic or something. I guess A delay on A1 could just delay things enough to stop the conflict. Such as maybe the DMA thinks it is supposed to be accessing a register, but the delay on A1 (with the capacitor) slows the cycle down enough to get around the issue..

I have routed A1 via the PLD on the next board. So I guess what I can experiment with it more then. Though I think a small delay after a DMA cycle will probably be enough to solve the issue.

[exxos]

Next up Blitter back in...

I suspect there might be a issue...

bltoops.jpg (56.53 KiB) Viewed 4119 times

[exxos]

ahhh, Blitter need to access ROM, I was only allowing the CPU to access ROM

This first benchmark is against a STE (with blitter enabled). 50MHz can give the blitter a run for its money in terms of desktop usage.

Of course we cannot run ST-RAM faster, so graphics tests with the blitter are only 5% faster (55%) is to be expected. But I thought the benchmark was interesting nonetheless.

1.jpg (82.23 KiB) Viewed 4009 times

This one is 50MHz with blitter enabled against a STE.

2.jpg (90.11 KiB) Viewed 4009 times

This one is 50MHz with blitter against a stock STFM (the money shot).

3.jpg (96.8 KiB) Viewed 4009 times

[PhilC]

Well done Exxos