Minimig Discussion Forum

Discussing the Open Source FPGA Amiga Project
It is currently Tue Dec 12, 2017 2:25 am

All times are UTC




Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Tue Apr 02, 2013 5:13 pm 
Offline

Joined: Fri Jan 20, 2012 9:32 pm
Posts: 55
chaos wrote:
....
02 - chip freq config (for chip PLL settings - speed etc)
03 - CPU freq config (for CPU PLL settings - speed etc)
....

Maybe, because of limited no of FPGA's clock multiplexers those 2 params could be combined into a one - 4 bits for chip and 4 bits for CPU settings? It should be more than enough :)


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

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
OK, good suggestions.

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

Good idea, there's plenty of room for more config bits. Maybe we could even turn every register into a 16-bit one.

MMrobinsonb5 wrote:
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.)

Yes, I agree we need a proper 32bit address.

Master of Gizmo wrote:
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.

That is a very valid suggestion, used in many SPI devices, like SPI flash. Like you described, it is used in more command-oriented communications. The slave implementation is more complex than in a simple address / reg variant, though. Plus, I see the OSD SPI link as more of a configuration interface than a command interface, but both variants would work equally well.

Although I prefer the address / reg variant, I don't think it is necessary to again rewrite the interface if you already have working code. There's many other things to do, like AGA and RTG :). Did you publish your atari core code somewhere - we could take a look and transfer that to the minimig core.

Master of Gizmo wrote:
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.

Yes, ofcourse I thought about that, as I'm already working on removing the amiga-side boot rom and using the OSD SPI link to upload the kickstart. That is the "system DMA" thing I described in my register proposal, which would allow write/read access to SDRAM and amiga reg bus.

madeho wrote:
Maybe, because of limited no of FPGA's clock multiplexers those 2 params could be combined into a one - 4 bits for chip and 4 bits for CPU settings? It should be more than enough

You are right, but some cores - like the C64, use ripple (logic divided) clocks, and you can use the space for setting up the clock divider counter. Plus some FPGAs have run-time configurable PLL settings ...

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


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Wed Apr 03, 2013 11:40 am 
Offline

Joined: Fri Oct 08, 2010 11:25 am
Posts: 6
I went the same way for the Replay code. There are two modules each with a SPI interface, Syscon and FileIO.

The Syscon contains the OSD, and has a new protocol. There are two 32 bit configuration registers which can be used as desired, one is dynamic and one updated only with system reset. There is another register for system control (DRAM timing etc). The OSD is higher resolution and in colour, but at a cost of an extra 2block rams. I have an option to use a font of the same resolution as the Minimig with the same memory footprint. The ARM also drives the external clock generator to set up the required frequencies for the selected video resolution.

The FIleIO module handles the low level SPI protocol for file transfer to the ARM, with the core specific code separated. It has a separate 8 bit low priority interface to the DRAM controller. The ARM can upload/download files to the full 32 bit address space. ROMs are specified in an ini file, and there is code to verify the memory against the file. The same memory bus can also be used to configure internal SRAM, and there are some example of this in the demo core.

I still have some work to do to get timing closure, and the cache logic around the CPU is tricky.
I'll get some binaries out with the new board and code release as soon as it is stable.

I have had an email discussion with some of you already. As the replay\lib and ARM is fairly specific to both Xilinx and my board I don't expect the code will converge with the other projects, but I hope the interfaces are sufficient that game / system cores can remain fairly generic.

The USB module is up and running as well. This sits on the pads of the PS2 connector and provides an external / internal USB connector.
This is currently a compile option and replaces the picoblaze based PS2 controller in the FPGA. I have some work to do regarding field firmware updates of the VNC2 chip I use before this is released as well.

Best,
MikeJ


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Thu Apr 04, 2013 9:00 am 
Offline

Joined: Tue Sep 25, 2012 7:15 pm
Posts: 105
chaos wrote:
Did you publish your atari core code somewhere - we could take a look and transfer that to the minimig core.


Of course: http://code.google.com/p/mist-board/

Nothing secret here :-)

BTW: Just drop me a note if you want write access.


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Thu Apr 04, 2013 9:06 am 
Offline

Joined: Tue Sep 25, 2012 7:15 pm
Posts: 105
chaos wrote:
I think that at this point it is wise to make the OSD protocol compatible with multiple cores


I am already using the minimig OSD for the atari core. I have only implemented the video part of it since the user IO is connected to the IO controller on my board and i don't have to pass the key events via SPI. But the OSD it itself uses identical code and thus looks the same:

http://www.youtube.com/watch?v=HTMV8tA2qwQ

We might also reduce the number of SPI channels used. I currently use three of them. The "FPGA" one and the one used for OSD and a third one for my board specific user io.

In the Atari core the FPGA channel has a whole new sematic and implements the atari specific io (IO controller direct SDRAM access, Atari-DMA, System control register). The OSD channel has only a small subset of the amiga OSD channel, but is compatible. And the user IO channel carries keyboard/joystick/mouse events and in the case of the atari st also carries the so called "ikbd" protocol which is used between the 68k cpu and the intelligent keyboard controller in a real st.

What i'd actually like to do is to cleanup the menu/osd to be more generic. Currently it's a huge switch statement and every screen is drawn be seperate code. I'd instead like to do a simple parser which paints the OSD based on some simple set of nested structs containing the menu structure. This should save a lot of code space and would seperate the contents from the menu logic.


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Fri Apr 05, 2013 9:48 am 
Offline

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
Master of Gizmo wrote:
Of course: http://code.google.com/p/mist-board/

Nothing secret here :-)

BTW: Just drop me a note if you want write access.


Thanks! Sure, write access would be nice :)


Quote:
What i'd actually like to do is to cleanup the menu/osd to be more generic. Currently it's a huge switch statement and every screen is drawn be seperate code. I'd instead like to do a simple parser which paints the OSD based on some simple set of nested structs containing the menu structure. This should save a lot of code space and would seperate the contents from the menu logic.

That's a great idea, as the current code is convoluted somewhat. I usually went the same way when designing menus - use an array of structs, which have pointers to parent and child items (so it's a sort of a tree), and a pointer to a function for any special code for specific item.

Oh, make sure you plan for bigger OSD display sizes :)

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


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Thu Apr 11, 2013 8:53 am 
Offline

Joined: Mon Dec 01, 2008 9:58 pm
Posts: 1568
Location: .de
minimig_emu wrote:
Here is my modified source code for ARM firmware (Minimig board).

I have this firmwre running and it is working good, well done :)

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


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Sat Jul 20, 2013 6:48 pm 
Offline

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
I made some progress with the OSD SPI protocol and have it working on the DE1 board.

As discussed, the protocol uses a byte command (address), followed by up to four bytes of register data, but this can easily be expanded by increasing the counter stop value. For special cases, like OSD display data and memory write, the command is followed by four address bytes and arbitrary many data bytes. As this requires a large counter in case of memory, I'm thinking of changing this into a paged system, where you write only the upper 16 bits of the address, the lower 16 bits come from a 16bit counter, so you could write a 2^16 bytes with a single command.

Here are the SPI commands:
Code:
// OSD SPI commands
//
// 8'b0_000_0000 NOP
// write regs
// 8'b0_000_1000 | XXXXXRBC || reset control   | R - reset, B - reset to bootloader, C - reset control block
// 8'b0_001_1000 | XXXXXXXX || clock control   | unused
// 8'b0_010_1000 | XXXXXXKE || osd control     | K - disable Amiga keyboard, E - enable OSD
// 8'b0_000_0100 | XXXXEANT || chipset config  | E - ECS, A - OCS A1000, N - NTSC, T - turbo
// 8'b0_001_0100 | XXXXXSTT || cpu config      | S - CPU speed, TT - CPU type (00=68k, 01=68k10, 10=68k20)
// 8'b0_010_0100 | XXFFSSCC || memory config   | FF - fast, CC - chip, SS - slow
// 8'b0_011_0100 | XXHHLLSS || video config    | HH - hires interp. filter, LL - lowres interp. filter, SS - scanline mode
// 8'b0_100_0100 | XXXXXFFS || floppy config   | FF - drive number, S - floppy speed
// 8'b0_101_0100 | XXXXXSMC || harddisk config | S - enable slave HDD, M - enable master HDD, C - enable HDD controler
// 8'b0_110_0100 | XXXXXXAA || joystick config | AA - autofire rate
// 8'b0_000_1100 | XXXXXAAA_AAAAAAAA B,B,... || write OSD buffer, AAAAAAAAAAA - 11bit OSD buffer address, B - variable number of bytes
// 8'b0_001_1100 | A_A_A_A B,B,... || write system memory, A - 32 bit memory address, B - variable number of bytes
// 8'b1_000_1000 read RTL version


Here is an excerpt from the code with the write registers implementation with the bit mappings:

Code:
// write regs
always @ (posedge clk) begin
  if (rx && !cmd) begin
    if (spi_reset_ctrl_sel)   begin if (dat_cnt == 0) {bootrst, usrrst} <= #1 wrdat[1:0]; end
    if (spi_clock_ctrl_sel)   begin if (dat_cnt == 0) end
    if (spi_osd_ctrl_sel)     begin if (dat_cnt == 0) {key_disable, osd_enable} <= #1 wrdat[1:0]; end
    if (spi_chip_cfg_sel)     begin if (dat_cnt == 0) t_chipset_config <= #1 wrdat[3:0]; end
    if (spi_cpu_cfg_sel)      begin if (dat_cnt == 0) t_cpu_config <= #1 wrdat[1:0]; end
    if (spi_memory_cfg_sel)   begin if (dat_cnt == 0) t_memory_config <= #1 wrdat[5:0]; end
    if (spi_video_cfg_sel)    begin if (dat_cnt == 0) {hr_filter, lr_filter, scanline} <= #1 wrdat[5:0]; end
    if (spi_floppy_cfg_sel)   begin if (dat_cnt == 0) floppy_config <= #1 wrdat[3:0]; end
    if (spi_harddisk_cfg_sel) begin if (dat_cnt == 0) t_ide_config <= #1 wrdat[2:0]; end
    if (spi_joystick_cfg_sel) begin if (dat_cnt == 0) autofire_config <= #1 wrdat[1:0]; end
//    if (spi_osd_buffer_sel)   begin if (dat_cnt == 3) highlight <= #1 wrdat[3:0]; end
//    if (spi_mem_write_sel)    begin if (dat_cnt == 0) end
//    if (spi_version_sel)      begin if (dat_cnt == 0) end
//    if (spi_mem_read_sel)     begin if (dat_cnt == 0) end
  end
end


Of course the code needs some cleanup. :)

For this version I tried to limit the changes to a minimum, but I would like to make further changes at least for the DE1 board:
- reset handling - since the boot overlay will no longer be required, the reset(s) can be completely controlled from the OSD block, by controlling the CPU and custom chips resets.
- Removing the highlight (invert) feature in RTL code - it seems MMrobinsonb5 already handles some pixel inversions in the firmware, it is probably best to completely handle it there. In that case the OSD is just a simple dumb display buffer.
- Replacing the current vertical OSD implementation with a horizontal one - this would allow us to use just a single font for both writing to Amiga display buffer and the OSD one.

The memory write is mostly done too, but there are still some bugs present, hopefully I will fix that over the weekend. The register read has to be fixed also.

Comments? Are there any registers which need extension?

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


Top
 Profile  
 
 Post subject: Re: Extending the OSD SPI protocol
PostPosted: Sun Jul 21, 2013 9:08 am 
Offline

Joined: Tue Dec 13, 2011 7:48 pm
Posts: 341
chaos wrote:
I'm thinking of changing this into a paged system, where you write only the upper 16 bits of the address, the lower 16 bits come from a 16bit counter, so you could write a 2^16 bytes with a single command.


That sounds like a good idea.

Quote:
- Removing the highlight (invert) feature in RTL code - it seems MMrobinsonb5 already handles some pixel inversions in the firmware,


I do? I'd forgotten that! But yes, I'm inclined to agree. The only possible use for it would be if the firmware were using it to change the inversion of the row without re-writing the contents, but if memory serves, it never actually does that - and SPI bandwidth doesn't seem to be a problem in practice anyway.

Quote:
- Replacing the current vertical OSD implementation with a horizontal one - this would allow us to use just a single font for both writing to Amiga display buffer and the OSD one.


Definitely.

Quote:
Comments? Are there any registers which need extension?


I'll just re-iterate my earlier comment about 8 bits not being enough for memory configuration. I know we don't yet implement all of this, but depending on the amount of SDRAM on the target board (either 8 meg or 32 meg in the current lineup, I think?) we can have up to 8 meg of Zorro II FastRAM at 0x200000, near enough unlimited Zorro III FastRAM at 0x40000000, and then there are potential turbo chipram and turbo kickstart features, too.

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


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

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:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Translated by Xaphos © 2007, 2008, 2009 phpBB.fr