Acorn Archimedes

[hubersn]

I'll investigate further. We have a Retro meeting coming up this weekend which focuses on "real" hardware, so any MIST-related work will have to wait a bit.

Thanks so far
hubersn

No need to hurry, I'm a bit exhausted from the R/W FDC work

Having no idea about FPGA development or the specific MIST framework...certainly the Archie core was not the first to gain write support for mounted disc images? Why did it need a MIST firmware upgrade? Please remember to explain it in easy words foran FPGA noob

...but couldn't resist to update the core a bit: increased the CPU clock by 30%. Helps on some games I think. The SDRAM clock couldn't be increased further, so you won't get 30% speedup. I would be interested in a benchmark comparing with the original A3000 now.

Try it:
https://github.com/mist-devel/mist-bina ... 190305.rbf

Thanks, I'll test it. I have just resurrected one of my A3000s and will have a go - meaningful benchmarks are in short supply under RISC OS, but I'll try. Maybe an empty for loop in BBC BASIC

BTW, using the MIST scandoubler would probably improve performance for compatible VGA monitors on PAL modes for MonitorType 0 and 1. Because the letterboxed modes used when MonitorType 4 is active use more memory bandwidth for video DMA, slowing down the CPU on average.

Hey, you could have a look at the ARM CPU core and implement the ARM3's cache

Have fun
hubersn

[slingshot]

Having no idea about FPGA development or the specific MIST framework...certainly the Archie core was not the first to gain write support for mounted disc images? Why did it need a MIST firmware upgrade? Please remember to explain it in easy words foran FPGA noob

Historical reasons I think...I guess the Archie FDC comes from the ST core, which handled the FDC specially (for supporting the ST floppy format). Now the SD-Card IO is handled by the same method as other cores (which has a 8-bit designation in the firmware, but that's no longer true - everything which is not ST or Minimig is 8 bits now in the firmware - Archie still has some special handling, the OSD menu and the keyboard/mouse, but not the FDC I/O).

Thanks, I'll test it. I have just resurrected one of my A3000s and will have a go - meaningful benchmarks are in short supply under RISC OS, but I'll try. Maybe an empty for loop in BBC BASIC

BTW, using the MIST scandoubler would probably improve performance for compatible VGA monitors on PAL modes for MonitorType 0 and 1. Because the letterboxed modes used when MonitorType 4 is active use more memory bandwidth for video DMA, slowing down the CPU on average.

Hey, you could have a look at the ARM CPU core and implement the ARM3's cache

Have fun
hubersn

Actually I found out while some games are better (e.g. Starfighter 3000 is playable now), some are worse (Cannon Fodder with music). The bottleneck seems to be the SDRAM now - it has to be improved (and hopefully it's possible to spare some cycles in the controller). The CPU has a small cache, maybe other DMA sources, like the video or sound can be cached, too (video ram caching helped a lot on Genesis and PC-Engine). But it's too complicated to add counting the probably 2 users of the core

[DrOG]

I'm the third, but have only very limited time to play with my MiST recently...

[Higgy]

My MiST (v1.2) would seem a good test for max SDRAM timings. It would not run with the early Archimedes Cores (and MSX).
So glad now that all Cores work on all MiST boards.
FPGA devs

(wishing I did Electronic Engineering, work has Graduate jobs advertised and mention FPGA & ASIC design. I'm too old and too many commitments now for such a big change )

[slingshot]

For those few, who still using the core, speeded up the SDRAM also (not by clock), result is quite acceptable in my tests:

https://github.com/mist-devel/mist-bina ... 190308.rbf

@higgy:
I'm neither FPGA designer, nor electrical engineer (but I had some electronical things as a hobby in my teenager years). I touched Verilog in 2017 first, VHDL last year Never too late to learn.
(And the first Archie cores didn't even run on my MiST - the SDRAM controller had some mistakes in it).

[hubersn]

For those few, who still using the core, speeded up the SDRAM also (not by clock), result is quite acceptable in my tests:

https://github.com/mist-devel/mist-bina ... 190308.rbf

Thanks for that, I'll do some tests late next week. Maybe someone could run ArmSI for some rough numbers?

http://ftp.uni-stuttgart.de/pub/systems ... benchmark/

Have fun
hubersn

[hubersn]

But it's too complicated to add counting the probably 2 users of the core

What we lack in numbers, we compensate with enthusiasm

Have fun
hubersn

[slingshot]

What we lack in numbers, we compensate with enthusiasm

Have fun
hubersn

Of course. But I would happily allow somebody else to implement an IDE hard disk One question: is the Amiga hdf and the Archimedes emulators' hdf files are the same container formats? Since ATA is already in the firmware in the form of minimig support, so probably it could be re-used.

[squid4]

What's the best way to get this to boot? Can't get the very last two cores to boot at all into RGB. The older cores did work after about 5 or more tries. Holding down the 0 numpad key - I don't have a VGA to test on. Particular ROM version required? Running 3.10 here - I think.

Update: First tip is to update the firmware, doh! When booting, best method I've found for RGB is to switch on, wait about 3 seconds then keep tapping the 0 numpad key. It should then beep and the Archy screen will be displayed. Works most times, if not switch off and try again.

[Hendricus]

I'm the third, but have only very limited time to play with my MiST recently...

I have been using the recent core as well this week. And I am delighted to see it has improved greatly! Tried Zarch and Conqueror and both appear to do very nicely. Well done for picking it up. I was saddened to hear the progress of Stephen Leary was halted when he no longer had the sources. But apparently it is progressing again. And now without any startup problems. I am as excited as a little kid!

[slingshot]

If you are able to make a working CMOS.RAM with MonitorType 0, then it'll be permanent.

[hubersn]

What we lack in numbers, we compensate with enthusiasm

Have fun
hubersn

Of course. But I would happily allow somebody else to implement an IDE hard disk One question: is the Amiga hdf and the Archimedes emulators' hdf files are the same container formats? Since ATA is already in the firmware in the form of minimig support, so probably it could be re-used.

Amiga ADF and Archimedes ADF are different formats, both physically and logically. Physically, Archimedes ADF is basically just a sector dump of either a DD floppy (800 KiB) or a HD floppy (1.6 MiB). 80 Tracks, 2 heads, 5 or 10 sectors/track with 1024 bytes/sector. Logically, RISC OS uses Filecore format (many variants out there called L, D, E, , E+ and F format), but you shouldn't need to worry about that - it is just presented as a sequence of logical blocks of 512 bytes. So what is needed is an implementation of the low-level IDE interface, the rest is handled by ADFS/Filecore. If the OS'es own driver (inside ADFS) should be used, I guess this would mean providing the IDE part of the C&T 82C710.

I have no idea how Amiga ATA is implented however, so I have also no idea if what I just said helps in any way!

Have fun
hubersn

[hubersn]

If you are able to make a working CMOS.RAM with MonitorType 0, then it'll be permanent.

I forgot to tell you...the 240 byte CMOS from !Configure I attached a few posts ago (not the 256 byte Arculator one, which I still cannot make head nor tail of) had the correct CMOS checksum, so I don't know why this does not work.

Have fun
hubersn

[slingshot]

Amiga ADF and Archimedes ADF are different formats, both physically and logically. Physically, Archimedes ADF is basically just a sector dump of either a DD floppy (800 KiB) or a HD floppy (1.6 MiB). 80 Tracks, 2 heads, 5 or 10 sectors/track with 1024 bytes/sector.

I know this, I'm curious about HDF, not ADF.

[slingshot]

If you are able to make a working CMOS.RAM with MonitorType 0, then it'll be permanent.

I forgot to tell you...the 240 byte CMOS from !Configure I attached a few posts ago (not the 256 byte Arculator one, which I still cannot make head nor tail of) had the correct CMOS checksum, so I don't know why this does not work.

Have fun
hubersn

Thinking about it, if it just 240 bytes, then it won't overwrite the missing bytes of the built-in values. Looking into the code, seems the first 16 bytes are the RTC or 0, so probably inserting 16 bytes _before_ the 240 should work.

[hubersn]

Amiga ADF and Archimedes ADF are different formats, both physically and logically. Physically, Archimedes ADF is basically just a sector dump of either a DD floppy (800 KiB) or a HD floppy (1.6 MiB). 80 Tracks, 2 heads, 5 or 10 sectors/track with 1024 bytes/sector.

I know this, I'm curious about HDF, not ADF.

It is a "large floppy" with consecutive blocks of 512 bytes size. Some emulators need and/or add an offset of 512 bytes to the start before the "real" image begins.

If you are interested in the logical format, I happen to have written some Java code to interpret Filecore format. Alternatively, Gerald Holdsworth has done a Delphi unit and an example application (that reads a lot more formats than just Filecore!): http://www.geraldholdsworth.co.uk/code. ... =DiscImage

Have fun
hubersn

[slingshot]

It is a "large floppy" with consecutive blocks of 512 bytes size. Some emulators need and/or add an offset of 512 bytes to the start before the "real" image begins.

If you are interested in the logical format, I happen to have written some Java code to interpret Filecore format. Alternatively, Gerald Holdsworth has done a Delphi unit and an example application (that reads a lot more formats than just Filecore!): http://www.geraldholdsworth.co.uk/code. ... =DiscImage

Have fun
hubersn

Ok, so it's just a sector dump, too. No, I don't want to write any filesystem driver

[DrOG]

What's the best way to get this to boot? Can't get the very last two cores to boot at all into RGB. The older cores did work after about 5 or more tries. Holding down the 0 numpad key - I don't have a VGA to test on. Particular ROM version required? Running 3.10 here - I think.

Update: First tip is to update the firmware, doh! When booting, best method I've found for RGB is to switch on, wait about 3 seconds then keep tapping the 0 numpad key. It should then beep and the Archy screen will be displayed. Works most times, if not switch off and try again.

I tried the latest core and firmware combo this weekend, and booted flawless into RGB pushing numpad 0.

[Estrayk]

I'll investigate further. We have a Retro meeting coming up this weekend which focuses on "real" hardware, so any MIST-related work will have to wait a bit.

Thanks so far
hubersn

No need to hurry, I'm a bit exhausted from the R/W FDC work
...but couldn't resist to update the core a bit: increased the CPU clock by 30%. Helps on some games I think. The SDRAM clock couldn't be increased further, so you won't get 30% speedup. I would be interested in a benchmark comparing with the original A3000 now.

Try it:
https://github.com/mist-devel/mist-bina ... 190305.rbf

Thank you very much slingshot, can be add a reset in the menu if it is possible?

[DrOG]

Thank you very much slingshot, can be add a reset in the menu if it is possible?

As slingshot wrote earlier:

I would also like a reset, but the Amber CPU doesn't have a reset signal at all.

Try Ctrl+Break as hubersn suggested.

[Chris23235]

I finally got the chance to try the latest versions of the core. On my RGB Monitor, the screen flickers in version 190305 and 190308, the earlier versions worked fine.

[DrOG]

I finally got the chance to try the latest versions of the core. On my RGB Monitor, the screen flickers in version 190305 and 190308, the earlier versions worked fine.

Which resolution do you use?

[Chris23235]

Bizarre bug, just tried it again today and everything was fine. Would say it is an issue with my monitor, but the older core versions worked fine and no other core showed any flickering.

[slingshot]

VIDC has some clock-domain crossing issues. If it's flickering - reload the core.

[Chris23235]

Ah, thanks for the info.