@minimig_emu & MMrobinsonb5: I've been testing this new ARM firmware and it seems rock-solid to me. Being able to load other cores is GREAT!May I add a couple of suggestions?

-Could you totally disable the annoying "illegal sector" messages? With this new firmware they are displayer and then hidden after seconds, but in some games (Jambala copied from floppy to HDD, for example) it causes the ARM firmware to be stuck with this message. Other games showing this message are: Super Gem'Z, Ishar (non-cracked version).No need for it since games work anyway.

-Since you are now building the ARM firmware and upgrading it, would it be possible to implement a way to change CPU speed from AmigaDOS?

-Could PacMan, Frogger... be rotated? Having to physically rotate the monitor to play them is very strange

thanks for this great work!The Minimig is an Amiga and two arcade machines at the same time

-Since you are now building the ARM firmware and upgrading it, would it be possible to implement a way to change CPU speed from AmigaDOS?

-Could PacMan, Frogger... be rotated? Having to physically rotate the monitor to play them is very strange

Changing OSD settings via Amiga side is FPGA stuff.I mentioned to had this in a play-time core but used reserved chipset register to set bits. This is not a good way because some title may use thise register as well and may cause random setting results.

This arcade cores are hard-built to display a 3:4 screen because the tubes was mounted in this way into most arcade game case.A change of 90° in display rotation would require game ROM rewrite.

______________________________________________JMP $00000BED ; will guru-meditation until next morning

I mentioned to had this in a pay-time core but used reserved chipset register to set bits. This is not a good way because some title may use thise register as well and may cause random setting results.

You'd be pretty safe if you put it not in the DFFxxx range but in Gayle's or the PCMCIA space.

One of these days I want to try putting an extra mouse register in too, so I can get mouse wheel events into the Minimig.

The protocol would (mostly) consist of an address / data pairs, 8 bits of each (we don't need 8 bits of address space yet, but for compatibility reasons it's best to stick to byte transfers over the SPI bus, even though some devices support different number of bits).

The master would first write a byte address, followed by a byte data write or read. The address selects the target register, which then receives the written data, or sends its value back to the master.

There are two options how to implement "special" registers - the OSD buffer and the system DMA. In both cases two or three registers represent the DMA address counter, which act as the base (starting) address for the DMA.

First option uses another register for the data port, so you'd write to the buffer by sending address / data 16 bit transfers to this register. Downside is that the bandwidth is halved, as each byte of data for the OSD or system DMA would need a two byte transfer. The upside is that this way is fully consistent with the protocol for other registers.

Second option is to use that register as a length indicator, and after writing that register, any bytes up to length would be directly interpreted as data. The downsides / upsides are just the opposite from option one: the protocol in no longer consistent with the other registers, but you can achieve full bandwidth.

I think that even with half the bandwidth the protocol would still be fast enough, so I'd go with the first option, as that allows a smaller, cleaner implementation of the SPI communication.

Here is a list of proposed register addresses and their approximate functions:

It would be great if all different cores on all the boards would (at least try to) support the same protocol for CPU - core communications. We should agree on a base set of registers that all cores would support (like ID, PLL config, OSD and DMA). Of course, not all cores need all of these features, but we should at least try to avoid register address clashes.

BTW, I'm working on an updated C64 core which will support ROM upload and floppy emulation among other things, so I'd like to use any updated SPI protocol that we will agree upon.

8 bits isn't enough for memory configuration. Could I suggest splitting it into at least two registersChip / SlowFast / Cache, etc.or for the sake of neatness, maybe even give Chip / Slow / Fast / Features a register each?

In fact anywhere we can already see a use for 6 or more of the 8 bits, I'd think about splitting the register into at least two, to leave headroom for future development. (Video config, for instance: I've already implemented separate scanline settings for normal and interlaced modes, which means 4 config bits. 4 more bits are needed for filtering, so that's all 8 bits used.)

Similarly, give your system DMA thing a fourth address register for bits [31:24]. I can touch three different FPGA devices without getting out of my chair that all have 32 meg of RAM. (Chameleon, MiST and the EBay-C3 board.)

Oooh - thanks for reminding me of that - as a stopgap measure I can use that bit and the associated keyboard shortcut for the PLL reconfig on the MiST.

That "Turbo" part doesn't exist in the MIST firmware anymore. I removed some of the code that was there but did not have a function anymore. However, it should be trivial to re-add it. But don't spend too much time searching for that code in the repository

8 bits isn't enough for memory configuration. Could I suggest splitting it into at least two registers

May i suggest not to limit the payload in any way? That way you don't need two registers. Actually you won't have to care at all, you can increase the size of that register whenever you need.

In the atari core every spi command begins with an 8 bit command id. And what comes afterwards is command specific. Some commands accept on byte, some 32 bits as parameters, some even several kilobytes.

Speaking of that: I still enjoy my "direct memory channel" that allows the io controller to read and write any area of the sdram at any time. Imho you should reserve space for that in your SPI protocol even if you don't need/want it now.

I have three commands:- Set address (takes a 32 bit address as parameter)- Write memory (takes any even number of bytes as parameter which are immediately written to ram)- Read memory (takes any even number of bytes as parameter which are immediately read from ram)

Last edited by Master of Gizmo on Tue Apr 02, 2013 9:25 am, edited 1 time in total.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum