23 July 2021, 09:46 | #21 |
Registered User
Join Date: Sep 2006
Location: New Sandusky
Posts: 942
|
Akiko is a busted design anyway because it requires the CPU to write to its registers, then read back the planar data, then write that back to the bitmap in chip memory.
If you wanted to do some real C2P acceleration, you'd build it into the glue logic on a CPU accelerator such that you created a chunky virtual bitmap that transparently wrote planar data to chip memory when the processor writes to it. You could either do this by setting up an entire mirrored bitmap address range, or just a 32-bit register to copy to that autoincremented its destination with each write. (The mirrored solution would be more complicated but would work better if you were refreshing individual pixels instead of the whole frame). |
23 July 2021, 11:04 | #22 | ||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
Quote:
The Pico supports up to 16MB SPI_flash. Having an extra-large Floppy could work. dumping things to SPI_flash: https://www.hackster.io/news/stacksm...m-6099bc95ff1e |
||
23 July 2021, 15:15 | #23 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,743
|
Paula transfer RAW bitstream with speed of 500kbps (for 250kbps MFM), floppy spin 300 revolution per second, simple math - 300/60=5 revolution per second i.e. single revolution per 200ms, if RAW bitstream transfer is 500kbps (in real case this is 507kbps for PAL and 511kbps for NTSC) then in 200ms you can write 101.4kb for PAL and 102.2kb for NTSC i.e. 12.675KB for PAL or 12.775KB for NTSC. This is more or less inline with RAW 3.5 inch floppy RAW capacity (2MB)
Quote:
Still most interesting for me is MC68000 emulation on RP2040 - or https://github.com/kstenerud/Musashi or perhaps https://github.com/notaz/cyclone68000 - using simple TTL logic to convert levels and at the same time interface PIO with MC68000 bus should open possibility to emulate for example fast MC68020 (richest instruction set) with decent clock some cache and at a cost of few $. |
|
23 July 2021, 17:28 | #24 | |||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
So for HD either that was missing or the MFM encoding. The result should be 25 KB of MFM encoded data per track. Quote:
This one has 16Mb SPI flash already on board ... Quote:
And there is no way you can emulate a 68020 with any decent speed on a 133MHz ARM - let alone without JIT or PJIT, but in interpreted mode... (and there is no space for JIT) I guess a highly optimized version of Cyclone could perhaps reach the original 68K@7Mhz on the Pico For anything fast you need something like PiStorm (1.6GHz) or Buffy (hardware takes care of the bus). No: The RP2040 is definitely the wrong chip for 68k-emulation/replacement. But shines as a controller or maybe small coprocessor - I really like the idea to use it as a poor mans gotek or hd-floppy-drive adapter (or both in one) Last edited by Gorf; 23 July 2021 at 21:56. |
|||
23 July 2021, 23:10 | #25 | ||||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,743
|
Quote:
Commodore goal (similarly to some IBM PS2 models) was to use DD floppy controller with HD floppy drive and floppies i.e. it was necessary to slow floppy revolution by half - Amiga and some low end IBM PS2 models used same mechanical floppy drives (able to spin 150RPM after detecting HD floppy). Quote:
Why? CPU emulation with something like 32KB cache should fit in 264KB of RAM. Quote:
Quote:
And in RP2040 PIO provide hardware MC68000 support (as i wrote earlier - using 74ACT595 and 74ACT597 should be possible to use single pin on RP2040 to input/output up to 32 bits in quick and pure HW manner and as in Amiga CPU bus is quite limited by chip set to approx 7..8MHz this gives us sane clocking speeds - 32 bits can be partitioned to for example 2 or 4 I/O further reducing clock speed). Definitely with help of some glue logic (simple CPLD or perhaps even very simple TTL's) it should be possible not only emulate MC68K bus but also capture Denise, Paula registers (like BPLxDAT, AUDxDAT etc) so HW extension can be made easily (even OCS/ECS scan doubler should be possible with RP2040 and few TTL's working as buffer and voltage translator). Some ideas already pointed earlier - for example real 16 bit mode for Paula (no longer arguing about 14 bit quality) - decode address on RGA, detect write to AUDxDAT pair, combine them, output to external DAC or on DAC made in software with RP2040 - something like 8 bit PWM preceded with 16..32 Delta Sigma bit quantized to 8 bit to feed 8 bit PWM (this best approach for HQ Delta Sigma - 16..32 times oversampled multi-bit high order DS [7-th 8-th order possible] to avoid problems of DS stability and inherently linear by design thanks to 8 bit PWM). But this is idea - perhaps 4bit PWM and 4th order DS will be suffcient for HQ Amiga DAC made on RP2040, use something like 4066 to switch between Paula DAC out and RP2040 DAC and you have true 16 bit playout from Paula. Or better - implement true 16 bit path - use RGA address planned for Mary (AAA AUD5DAT) , some FIFO , feed data by CPU in Amiga and add 16 bit audio to 8 bit one. |
||||
24 July 2021, 01:24 | #26 | |||||||||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
That is what I am talking about One track are on a normal Amiga DD disk are 11x512 byte as in RAM or 11x1024 bytes as MFM encoded data. A little over 11 kb . So with 2x80 tracks this are 880 KB in RAM or 1760KB MFM encoded. On a HD-Floppy that is double. (That is what we were talking about.) So to buffer one HD-track we need roughly 25KB. Quote:
Quote:
Quote:
Quote:
PiStorm on a beefy RasPi 3b with 1.2 GHz and loads of RAM can emulate a 80 MHz 030.... the Pico in at least 90% slower ... we are down to a 8MHz 68K CPU Quote:
Can you point me to some documentation about that? Quote:
for something that is probably not even faster than than an old 68000 - especially if you want to be cycle exakt ... and if you somehow manage to write a faster emulation, you still do not have any fast ram to make use of the speed. Quote:
or one per chip? A simpel scandoubler would be possible - but not a flicker fixer - again not enough RAM to store a frame and have some code... Quote:
I guess a complete Paula replacement could be possible - combining sound and floppy and serial functionality ... with some improvements like HD-floppy and/or visual floppies and better sound, more channels similar to the Vampire... That makes much more sense than 68K emulation. Last edited by Gorf; 24 July 2021 at 01:44. |
|||||||||
24 July 2021, 20:41 | #27 | |||||||||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,743
|
nope http://amiga-dev.wikidot.com/hardware:adkconr
You have 2 or 4uS i.e. 500 or 250 kbps RAW i.e. 250 or 125kbps MFM. Quote:
My calculation are ok - 500kbps in 200mS (500*0.2)/8)=12.5KB - this is data length - now RP2040 need to encode this to MFM data and this will give us 25KB (but MFM encoding/decoding can be done on the fly perhaps even by PIO itself) so in theory no need to store MFM track. Once again - to communicate with RP2040 Paula will use not encoded data i.e. efficiently doubling transfer speed - this should be not a problem as communication can be block oriented and between devices using precise clocking thus less sensitive than analogue magnetic storage. Quote:
Currently all my time is dedicated for my home construction works - perhaps in 2..3 years from now... Quote:
https://www.hackster.io/news/robin-g...z-c3677aa5daac Quote:
Perhaps instead C we need ARM asm emulation, some clever way but still should be possible especially after RP2040 overclocking to perhaps something like 12xsystem clock in Amiga (340MHz). Quote:
Quote:
Small virtual cache may compensate lack of FAST RAM and external FAST RAM always can be used. Quote:
But as RGA and data are shared by all Amiga chips then this part is sharable in RP2040. Quote:
Quote:
|
|||||||||
25 July 2021, 16:10 | #28 | |||||||||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
My guess is, Paula does need MFM data to be able to lock itself to the signal - also start/end codewords are "incorrect" MFM ... that would not work in unencoded data ... and a real floppy would also need MFM. So it is probably not worth decoding a track, but to buffer the whole 25KB... This is of course not true if we provide a gotek-like functionality, or replace Paula completely Quote:
Quote:
Quote:
so 300 MHz seems to be the practical limit here ... are there any benchmarks for overclocked devices? Quote:
Quote:
https://github.com/kilograham/b-em Quote:
(Also there are already enough other accelerator projects in my opinion ... and personally I am not interested in anything slower then a 060) Quote:
It's more with overscan or AGA... Quote:
(CPU would have lowest or no priority for me) Last edited by Gorf; 25 July 2021 at 16:19. |
|||||||||
26 July 2021, 21:43 | #29 | |||||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,743
|
Quote:
25KB buffer should fit in 200KB RAM (even 50KB should fit - how big can be ARM ASM MFM encode/decode code?) NOR is for code, NAND for data... better 2GB than 16MB. Quote:
this is very good question - i'm not aware of anything else than https://www.eembc.org/ - https://www.eembc.org/coremark/scores.php and https://github.com/protik09/CoreMark-RP2040 and https://github.com/nickfox-taterli/pico-coremark Perhaps but... float and arithmetic can be done in "single MC68000 cycle"... and even this is worth effort. Quote:
Not sure about why ARM need so many cycles to emulate MC68000. Quote:
Quote:
Even some of them would be nice... |
|||||
27 July 2021, 02:29 | #30 | |||||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
Never said 25KB would not fit or would be a problem - I was just correcting the number. Quote:
Maybe you are lucky and that is not the case, but for a conservative consideration I would not assume anything over 300MHz is working without hassle. Quote:
(the M0+ does not even provide integer division, but the RP2040 provides a special register for that...) Quote:
And many 68K instructions have no equivalent at all on AARCH and need emulation of these can take up many host-cpu instructions... And you also need to keep track of all the registers of your emulated CPU and the Flags, the interrupt lines .... Als since limited RAM excludes any JIT or PJIT you have to look up every 68K-instruction every time... Quote:
I guess every custom-chip should be possible after a lot of work... but maybe we should start with something much easier? |
|||||
27 July 2021, 15:59 | #31 |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 540
|
Would Agnus be a good starting point? It's in all models, different adapters should be possible for the DIP48 and PLCC84 packages and it's pretty well documented. I imagine it should be feasible to do different configs for different versions but they mostly do similar things.
Some Agnuses are unobtainium, so it may help bring quite a few systems back to full strength that otherwise might end up in landfill. |
27 July 2021, 18:13 | #32 | |||||||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,743
|
Quote:
But this is of course pure speculation and tests are required - i can be wrong on this. Quote:
Ok let's correct numbers then. 500kbps transfer speed from Amiga and to Amiga (RAW data, no MFM), normal (300RPM) rotation speed for floppy - 300 RPM means 5 revolution per second i.e. single track can be long for 200ms maximum - Paula transfer speed for PAL is approx 507kbps so 507*0.2=101.4kb per track i.e. 12.675KB of data on single track - this is HD FDD requirement (PIO should be capable to encode and decode MFM on the fly - if not then requirement for buffer need to be doubled in case of floppy). If RP2040 will be used as cheap (but slow - only 500kbps) HDD substitute then of course buffer size required can be lower or higher (IMHO lower as sector size - max 4096 bytes) will be sufficient - more can be used to cache some data. Quote:
Quote:
So having this as simple co-processor for MC68K could be beneficial. Quote:
Quote:
and this is PIO that make possible to emulate in software DVI 1080p50 that's why is should be possible to emulate relatively slow Amiga bus. I can imagine lot of extensions made with RP2040 like real DMA HDD etc. But i also agree - no rush, start from simple things like CIA's - they can be easily damaged so we need cheap replacement and having possibility to add native USB devices like KB can be important too. Quote:
Last edited by pandy71; 27 July 2021 at 18:22. |
|||||||
29 July 2021, 19:22 | #33 | ||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
simple 68k instructions with an equivalent ARM instruction and no indirect or even double indirect memory operations could be done in 4-6 instructions. Others like binary coded decimal will be huge ... All direct and indirect memory operations will be very slow - determined by the 68k bus... If you want to use whats left if the internal Pico RAM as cache, you need to do all the cache logic by foot: there is no MMU. This might destroy all benefits of a faster RAM access. You could however probably "hardwire" some small portion (16K, 32K ?) to a non existing memory location (Z3 space) and use it als FastRAM. But then you would probably need to provide a mechanism for the OS to only use this tiny space for certain tasks... Well even the "hardwiring" would probably need boundary checks and address translation for every load and store operation. (As far as I understand the SIO /single-cycle software controller of the PIO) can only do 32-bit reads/writes ... so while the PIO might be able to mimic the 68K-bus, you still need to take care of the 16 or 8 bit wide access by hand... please correct me if I am reading the docs wrong.) Correction on this: you can use the DMA for this ... well at least for one pre determined bus-width (e.g. 8bit OR 16bit) - I could not find a solution for a variable bus-width. We would probably need to sacrifice the second PIO block - one block for word access and one for byte access ... The PIO blocks are "copper-like" co-processors, but your list can only be 32 instructions long - don't know if the 68K-bus is doable within these restrictions, but it would surely be an interesting task. Quote:
The problem with Agnus is probably more the number of pins ... there you need quite some assisting logic. Last edited by Gorf; 29 July 2021 at 19:53. |
||
29 July 2021, 19:33 | #34 |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
The mentioned use case a line-doubler made me think.
It should be possible to do more with this ... specifically all things that process video-output line by line without the need of storing a field or frame. The DCTV, HAM-E and Graffiti work this way ... Would a "all in one" solution be possible? Last edited by Gorf; 29 July 2021 at 22:56. |
29 July 2021, 20:20 | #35 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,743
|
Quote:
I would add to this also extended RAMDAC i.e. translation of 12 bit to real 24 bit and adding more CLUT entries - like 16k or more if possible. Not sure about DMA capability in RP2040 but perhaps it could be possible to do most of data processing without involving CPU to much... I see only one problem - to do efficient CLUT extension RP2040 need to have access to data lines and RGA address - scandoubler with emulation of DCTV, HAM-E and similar can be done purely on digital 12 bit video + H and V sync + CLK. Also perhaps some SPI RAM could be an option but... they are very expensive and overall not worth of effort. Almost forgot to add to DCTV or HAM-E functionality true 16 bit audio part so audio samples can be embedded in video and extracted by RP2040 (this area of course can be blanked by RP2040 so for example 16:9 format can be created from 5:4 (4:3). |
|
29 July 2021, 22:07 | #36 | |||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
You would overwrite the same memory region over and over (e.g. a line) From there the CPU has to take over and process the data. You only(!) need to get the timing right ... there you need a clever algorithm to sync to the hbank and vblank ... (you can start and stop the PIO at the right time once you got this) Quote:
An other way is how the Graffiti does it: send the colour-entries encoded in the first line of your screen. Quote:
Via Parallel Port you could transfer fast enough for CD-Quality (150KB/s) ... but it will take quite some CPU-time. On the other hand you would need also CPU-time to encode the audio to screen-artefacts. https://lallafa.de/blog/2015/09/amig...st-can-you-go/ (... there was someone in the past who did a low-level analog version of this: black and white stripes on the scene and audio via composite output Last edited by Gorf; 29 July 2021 at 22:24. |
|||
29 July 2021, 22:21 | #37 |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
OK - now I think I found the right project to start with.
Much simpler and yet quite useful - and most work is already done. (Damn you Atari ST - once again first to the market ...) https://github.com/fieldofcows/atari-st-rpikb USB keyboard, mouse and joystick on a Mega ST with only a Pico in between. Joystick and mouse should work with very little adjustments. One could also implement some features other adapters are lacking, like proper mousewheel and game-pad support, analog joysticks.... The ST keyboard controller of course is different (HD6301), but it is also a serial protocol |
30 July 2021, 11:15 | #38 | |||||||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,743
|
Quote:
Quote:
Quote:
Perhaps even external FAST RAM can be possible (two PIO dedicated, additional glue logic) Quote:
Assuming synchronous operation with Amiga clock (by feeding clock to or PIO input or as main RP2040 clock some things can be simplified significantly. By splitting 16 bit data bus on two 8 bit halves i think you can solve endianess problem. Quote:
Quote:
or just build CIA's++ - new registers and read all this by CPU? Quote:
Of course Akiko could be part of CPU emulation or even add real block transfer for CPU (so create DMA-like functionality) or perhaps modify Denise to interpret bitplane data as chunky (so create 4, 16, 256 color chunky format on top of currently implemented planar formats - IMHO this is most desired approach). Last edited by pandy71; 30 July 2021 at 11:30. |
|||||||
30 July 2021, 11:41 | #39 | |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
For the A1000 keyboard even the same phone-jack ist used as in this projekt. For A2/3/4000 you only need a different connector, but the same amount of wires. Only the serial protocol differs. |
|
30 July 2021, 11:50 | #40 | |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
You provide one additional register that behaves like a FIFO Set up the bitplane pointers as usual CPU writes 8 times to the FIFO register Agnus spreads it to the bitplanes Meanwhile CPU calculates next pixels CPU next 8 reads Agnus ..... |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Pico PSU inside of Amiga 1000 | blindguy | Hardware mods | 4 | 03 December 2019 07:53 |
Pico PSU | Daishi | support.Hardware | 9 | 20 November 2019 22:48 |
Raspberry Pi Mini to 1200 Clockport Advice | betajaen | Hardware mods | 33 | 06 August 2018 11:38 |
Does Pico PCMCIA Ram work with Amiga? | Tipper112 | support.Hardware | 3 | 07 May 2013 10:20 |
Pico PSU for amiga in tower | mrodfr | support.Hardware | 10 | 01 September 2009 08:59 |
|
|