Minimig Discussion Forum

Discussing the Open Source FPGA Amiga Project
It is currently Fri Oct 20, 2017 6:07 pm

All times are UTC




Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Sat Mar 30, 2013 4:11 pm 
Offline

Joined: Thu Jun 18, 2009 9:54 am
Posts: 349
@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 :P

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


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Sat Mar 30, 2013 4:38 pm 
Offline

Joined: Mon Dec 01, 2008 9:58 pm
Posts: 1568
Location: .de
gaula92 wrote:
-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 :P


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


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Sat Mar 30, 2013 4:50 pm 
Offline

Joined: Sun Dec 28, 2008 3:00 pm
Posts: 59
boing4000 wrote:
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.


No, it needs "only" to rewrite the video controller for the core.
I think Mark McDougall dit it for Pacman and Moon Patrol.


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Sat Mar 30, 2013 4:55 pm 
Offline

Joined: Tue Dec 13, 2011 7:48 pm
Posts: 341
boing4000 wrote:
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.

Playtime cores are always fun :D

_________________
~ Amiga 4000/030 ~ Amiga 1200 030/50MHz ~ Turbo Chameleon 64 ~ Altera DE1 with Minimig core ~
Details of my projects: http://retroramblings.net


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Sat Mar 30, 2013 4:59 pm 
Offline

Joined: Fri Dec 09, 2011 11:31 am
Posts: 91
Dirk wrote:
boing4000 wrote:
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.


No, it needs "only" to rewrite the video controller for the core.
I think Mark McDougall dit it for Pacman and Moon Patrol.


Rotate screen is not problem, but is need change scaling screen.
Otherwise, you will not see part of the picture!


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Mon Apr 01, 2013 8:34 pm 
Offline

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
Here is my proposed SPI protocol update.

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:

00 - core version / ID
01 - reset control (CPU & chip, space for extensions)
02 - chip freq config (for chip PLL settings - speed etc)
03 - CPU freq config (for CPU PLL settings - speed etc)

04 - chipset config (NTSC, OCS, ECS, AGA, autofire, ...)
05 - CPU config (type, ...)
06 - memory config (chip, slow, fast, cache, ...)
07 - video config (scanlines, interpolation filter, dithering)

08 - floppy config (speed, no. of floppies)
09 - hard disk config (...)
0a - not implemented
0b - not implemented

0c - OSD control (enable, keyboard, background, ...)
0d - OSD address [15:8]
0e - OSD address [7:0]
0f - OSD buffer port (or length value)

10 - system DMA address [24:16]
11 - system DMA address [15:8]
12 - system DMA address [7:0]
13 - DMA buffer port (or length value)

Any thoughts, any missing registers?

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.

Cheers!

_________________
** my minimig builds: http://somuch.guru/ **


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Mon Apr 01, 2013 10:26 pm 
Offline

Joined: Tue Dec 13, 2011 7:48 pm
Posts: 341
Looks good to me. Just a couple of suggestions.

8 bits isn't enough for memory configuration. Could I suggest splitting it into at least two registers
Chip / Slow
Fast / 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.)

_________________
~ Amiga 4000/030 ~ Amiga 1200 030/50MHz ~ Turbo Chameleon 64 ~ Altera DE1 with Minimig core ~
Details of my projects: http://retroramblings.net


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Tue Apr 02, 2013 8:59 am 
Offline

Joined: Tue Sep 25, 2012 7:15 pm
Posts: 105
MMrobinsonb5 wrote:
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 :-)


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Tue Apr 02, 2013 9:12 am 
Offline

Joined: Tue Sep 25, 2012 7:15 pm
Posts: 105
MMrobinsonb5 wrote:
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.

Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Tue Apr 02, 2013 9:14 am 
Offline

Joined: Mon Dec 01, 2008 9:58 pm
Posts: 1568
Location: .de
Looks good to me too, nice idea :)

To disable scanline in interlace mode, a simple logic in FPGA will do the job.
For sure to make it selectable via OSD (disable scanline at interlace) an own SPI bit will be required.

_________________
_____________________________
JMP $00000BED ; will guru-meditation until next morning


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Translated by Xaphos © 2007, 2008, 2009 phpBB.fr