search

mist-devel / mist-binaries

Firmware and core binaries for the MIST board
203 stars 48 forks source link

Archimedes Core - Issues caused by SDRAM timing? Possible to use MSX Core fix? #39

Closed Higgy69 closed 5 years ago

Higgy69 commented 7 years ago

Hello,

There are documented issues with the Archimedes Core running on some MiST boards, could this be solved using the SDRAM timing fixes that were used on the MSX Core:

https://github.com/robinsonb5/OneChipMSX/commit/032d2dc4e18cf49f32fd6d0bd89442182468546c

Sorry I don't have enough knowledge to incorporate the changes and build a binary.

Issues of Archimedes Core being discussed on Atari-Forum:

http://www.atari-forum.com/viewtopic.php?f=101&t=27637&sid=b6a289b7a2a2dff36a34e061fca467bc&start=25

MiST Archimedes Cores:

https://github.com/mist-devel/mist-binaries/tree/master/cores/archimedes

Thanks

ghost commented 7 years ago

I will try and find some time to look at this.

S.

On Thu, Jan 26, 2017 at 2:10 PM, Higgy69 notifications@github.com wrote:

Hello,

There are documented issues with the Archimedes Core running on some MiST boards, could this be solved using the SDRAM timing fixes that were used on the MSX Core:

https://github.com/robinsonb5/OneChipMSX/commit/ 032d2dc4e18cf49f32fd6d0bd89442182468546c http://url

Sorry I don't have enough knowledge to incorporate the changes and build a binary.

Issues of Archimedes Core being discussed on Atari-Forum:

http://www.atari-forum.com/viewtopic.php?f=101&t=27637&sid= b6a289b7a2a2dff36a34e061fca467bc&start=25 http://url

MiST Archimedes Cores:

https://github.com/mist-devel/mist-binaries/tree/master/cores/archimedes http://url

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mist-devel/mist-binaries/issues/39, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPNmUGFSQqWU75C-oJjJd80ayyVLdgfks5rWKlugaJpZM4LurMT .

-- Stephen Leary

ghost commented 7 years ago

I looked at my code. Its impossible for me to support different RAM timings as my design requires specific timings on specific clock cycles.

On Thu, Jan 26, 2017 at 2:19 PM, Stephen Leary sleary@vavi.co.uk wrote:

I will try and find some time to look at this.

S.

On Thu, Jan 26, 2017 at 2:10 PM, Higgy69 notifications@github.com wrote:

Hello,

There are documented issues with the Archimedes Core running on some MiST boards, could this be solved using the SDRAM timing fixes that were used on the MSX Core:

https://github.com/robinsonb5/OneChipMSX/commit/032d2dc4e18c f49f32fd6d0bd89442182468546c http://url

Sorry I don't have enough knowledge to incorporate the changes and build a binary.

Issues of Archimedes Core being discussed on Atari-Forum:

http://www.atari-forum.com/viewtopic.php?f=101&t=27637&sid=b 6a289b7a2a2dff36a34e061fca467bc&start=25 http://url

MiST Archimedes Cores:

https://github.com/mist-devel/mist-binaries/tree/master/cores/archimedes http://url

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mist-devel/mist-binaries/issues/39, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPNmUGFSQqWU75C-oJjJd80ayyVLdgfks5rWKlugaJpZM4LurMT .

-- Stephen Leary

-- Stephen Leary

robinsonb5 commented 7 years ago

What I adjusted on the MSX core wasn't RAM timings as in CS2/CS3 latency, but just timing constraints for the communication between the FPGA and the external SDRAM chip, and then adjusting the phase shift of the external SDRAM clock.

By the way, my MIST is a pre-production board and I haven't yet managed to get anything out of the Archimedes core - the monitor just stays in standby. But I don't know enough about the Archie to know even which ROM file I should be using. Could you give me the MD5 of a known working ROM file so I can be sure that the core should work?

Higgy69 commented 7 years ago

The strange thing is release r814 and r991 work fine. But the last release r1028 (and the one with nice fixes) does not work. Monitor just stays in 'standby'.

https://github.com/mist-devel/mist-binaries/tree/master/cores/archimedes

I don't know if it is related or that they were just published on the same day, but there was also a MiST firmware update. Not sure if the update was because of the r1028 Archie? Could the MiST firmware update cause the issue?

This ROM works with the first two core release:. http://oliverb.drobe.co.uk/downloads/risc_os_3.zip

Rename extracted zip file to riscos.rom and place in sd card ROOT.

robinsonb5 commented 7 years ago

OK interesting. Thanks for the ROM link - that's what I needed to get it working. I've tested with the oldest and newest core and they behave the same on my MIST. From cold, when I turn on the MIST the monitor remains in standby, and the serial output from the microcontroller shows the ROM upload happening, the USB devices being configured, then just keeps repeating a constant stream of the following two lines: ARCHIE: KBD timeout in reset state ARCHIE: KBD TX ff (1) So I guess the core's not coming out of reset after the ROM upload's finished?

If I then press the reset button one of three things happens:

Hendricus commented 7 years ago

I am experiencing the same issue as reported by Higgy69. Release r991 works with the linked rom file, but not so for the r1028. I have tried if I can have an occasional correct boot (as reported by robinsonb5) with the last core to see what the difference is between the core versions, but after many retries with the reset button I need to conclude there is no successful reboot with the MiST I have got.

There isn't much you can do with core r991. When booted up there is a HD on the icon bar which is not connected to a hard disk image file, and this cannot be set via the OSD either. There are no floppy drives on the icon bar, but these can be added via the !Configure tools and the floppy images can be selected via the OSD. Unfortunately, the changed configuration is not being retained. So with every reset you need to add the floppy drives again. Switching from screen mode 27 is not advisable, as most other modes do not work, and when you switch back to mode 27 it flickers.

It would be great if the core could be fixed and there is a way to keep RiscOS configuration settings and add ST506, or IDE, or SCSI hard disk drives and have the ability to connect these with hard disk image files via the OSD.

harbaum commented 7 years ago

The archie core simply has never been finished. We (mainly Stephen) spent a few weks work and only a few people ever used it. So there wasn't any additional effort put into it.

ghost commented 7 years ago

I also was not made aware of sdram timing differences on the production boards. I only have a prototype so cannot test

Sent from my iPhone

On 22 May 2017, at 15:02, Till Harbaum notifications@github.com wrote:

The archie core simply has never been finished. We (mainly Stephen) spent a few weks work and only a few people ever used it. So there wasn't any additional effort put into it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

robinsonb5 commented 7 years ago

I'm not sure whether the timing is actually different at the datasheet level, or whether it's that the chips on the production boards are less forgiving if a core drives them slightly out of spec. (But mine's a prototype board, too, so the issues I'm seeing aren't due to the different RAM chip on the newer boards.)

Hendricus commented 7 years ago

Most people realise it is a hobby project, and we appreciate very much the effort that has been put into it to get to the state the core is in at present. I think the number of people that have been trying it and want to play with the core (either for nostalgia reasons or as a pure hobby exploring the systems of the 80's and 90's) is underestimated.

Sure, RiscOS can be used on the Raspberry Pi and is being maintained for years to come, but that is not the Archimedes experience. There is a reason an emulator is available running in RiscOS 5 in order to be able to use classic RiscOS 3 software.

In my student years I had an Archimedes A410 and I loved it, but it broke down. Later I got an A3010 but it had not survived the many house moves I made. It would be great to have the real thing again in that little box called MiST. I am sure there are plenty who feel the same.

Please, be assured that any additional effort to make improvements on the Archimedes core is most welcome.

fordp2002 commented 7 years ago

Is there a post on stardot for this project. That is the best place to get people to help.

Higgy69 commented 7 years ago

Hi all. I put in the original Issue. Please make sure my SDRAM comment is not a 'red herring'. I was just thinking of potential differences between MiST PCB's. And also I heard that the MSX Core which had issues was due to RAM timings.

There is also an issue with the latest Sam Coupe Core: [https://github.com/sorgelig/SAMCoupe_MIST/issues/1] - it works on sorgelig's v1.3 board. The previous release worked fine on my board, but not the latest?!

There is something between PCB's that is causing compatibility issues. I have a v1.2 . I was trying to get this discussed on the forum so that clever people could hopefully solve the issue or create design parameters to ensure that Cores work on all PCB's. - I would like Core developers hard work to be enjoyed by all.

I don't think I am alone in wanting this compatibility issue found and a fix generated. My main reasons for buying a MiST was the ST, Archie & Sam Coupe Cores :(

Thanks for all your hard work guys and I hope I have not written anything out of place, you guys are Hardware Gods!! :)

harbaum commented 7 years ago

The prototype boards and the first batch should electrically be really the same. I actually work on both all of the time and never noticed a difference. Later the RAM chip wasn't available anymore and Lotharek had to add a new one. But the specs according to the data sheet are the same. However, that doesn't mean that the chips behave the same when operated outside the specs which easily happens ...

ghost commented 7 years ago

With the Archie core i was pushing the RAM to 128Mhz. I dont know if this is within the specs still.

I know that i used a simulation model of the RAM to check everything. Perhaps more constraints need added for the timings. I'm more familiar with timing constraints in ISE than Quartus.

Cheers Stephen

On Wed, May 24, 2017 at 8:46 PM, Till Harbaum notifications@github.com wrote:

The prototype boards and the first batch should electrically be really the same. I actually work on both all of the time and never noticed a difference. Later the RAM chip wasn't available anymore and Lotharek had to add a new one. But the specs according to the data sheet are the same. However, that doesn't mean that the chips behave the same when operated outside the specs which easily happens ...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mist-devel/mist-binaries/issues/39#issuecomment-303831494, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPNmVbCf0Y53_BNqS7QSH_drU_44sXzks5r9IkogaJpZM4LurMT .

-- Stephen Leary

harbaum commented 7 years ago

The Atari ST core also runs the ram at 128mhz. And it runs on all boards equally as far as i know.

ghost commented 7 years ago

What are the actual symptoms? Video breakup in the higher modes? if so thats simply down to lack of video bandwidth.

The Archie VIDC needs to cross arbitrary clock domains... Programmably selectable 24,25,36 etc Mhz. This is much more tricky than the other cores.

Cheers Stephen

On Wed, May 24, 2017 at 9:06 PM, Till Harbaum notifications@github.com wrote:

The Atari ST core also runs the ram at 128mhz. And it runs on all boards equally as far as i know.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mist-devel/mist-binaries/issues/39#issuecomment-303836406, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPNmdrK30U8fH15b8GOa8tUo-j9t7Eyks5r9I2vgaJpZM4LurMT .

-- Stephen Leary

sorgelig commented 7 years ago

It also may depend on how often system access the RAM. I've noticed interesting effect while developing SDRAM board for DE10-nano board. ZX core uses 112MHz for SDRAM and works well, while SAM Coupe on 96MHz has snow on the screen. ZX uses FPGA RAM as a shadow display RAM, so display is drawn from FPGA RAM, and SDRAM has quite relaxing access. On SAM Coupe where video can be in any place of 512KB, i couldn't use FPGA RAM so i had to use SDRAM for display drawing as well and SDRAM is quite busy there. So, SDRAM clock is not the only the factor. For my SDRAM board i've fixed the problem by 3pF capacitor connected near the CLK pin of SDRAM chip to filter out noise from other SDRAM signals.

harbaum commented 7 years ago

And these are 133mhz chips. So yes, 128mhz is within the specs but there's not much tolerance left with respect to signal setup times etc ...

Higgy69 commented 7 years ago

It just does not boot. Black screen. On Screen Display does not work.

Like the Sam Coupe Core, whatever was changed or added to the last Archie release stopped the Core from working.

Higgy69 commented 7 years ago

I just held down Numpad 0 and reset the MiST. I get a pink screen with some black blocks. But now I can open OSD. Although it repeats itself vertically.

Higgy69 commented 7 years ago

Now I reset with no buttons pressed and I get an orange/red screen with same black blocks But the MiST leds flashed as if it was booting but it has gone to a black screen. OSD works but again it is repeated vertically.

ghost commented 7 years ago

Its an Acorn.. .It does RAM accesses constantly by design. Including some burst mode stuff. Maybe the burst mode is an issue.

S.

On Wed, May 24, 2017 at 9:16 PM, sorgelig notifications@github.com wrote:

It also may depend on how often system access the RAM. I've noticed interesting effect while developing SDRAM board for DE10-nano board. ZX core uses 112MHz for SDRAM and works well, while SAM Coupe on 96MHz has snow on the screen. ZX uses FPGA RAM as a shadow display RAM, so display is drwan from FPGA FAM, and SDRAM has quite relaxing access. On SM Coupe where video can be in any place of 512KB, i couldn't use FPGA RAM so i had to use SDRAM for display drawing as well and SDRAM is quite busy there. So, SDRAM clock is not the only the factor. For my SDRAM board i've fixed the problem by 3pF capacitor connected near the CLK pin of SDRAM chip to filter out noise from other SDRAM signals.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mist-devel/mist-binaries/issues/39#issuecomment-303839063, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPNmQEgC9DNcLsPekEUc4Cic_8hq0lTks5r9JAngaJpZM4LurMT .

-- Stephen Leary

ghost commented 7 years ago

Any sound?

On Wed, May 24, 2017 at 9:28 PM, Higgy69 notifications@github.com wrote:

Now I reset with no buttons pressed and I get an orange/red screen with same black blocks But the MiST leds flashed as if it was booting but it has gone to a black screen. OSD works but again it is repeated vertically.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mist-devel/mist-binaries/issues/39#issuecomment-303842162, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPNmR-CeSYpV3c_-qeWpNl6VHRLvAFWks5r9JL3gaJpZM4LurMT .

-- Stephen Leary

Higgy69 commented 7 years ago

2 pops from the speaker. 1 soon after MiST Reset is pressed, then another about 1 sec later.

robinsonb5 commented 7 years ago

The speed grade of the SDRAM chip on my pre-production MIST is -75. According to the datasheet this grade can do 133MHz, but only with CL3. Am I right in thinking the Archie core is using CL2?

And yes, using burst mode does make the timing significantly less forgiving.

Hendricus commented 6 years ago

Hi Stephen. I noticed you had the idea to revisit the MiST and Acorn scene. That sounds great! I hope we will get some news from you. We would love to have an updated core that is more robust :-)

gyurco commented 5 years ago

I think the stability issues are fixed now. Anyone wants to improve the core?