Minimig Discussion Forum
http://minimig.net/

Extending the OSD SPI protocol
http://minimig.net/viewtopic.php?f=7&t=570
Page 1 of 3

Author:  MMrobinsonb5 [ Tue Mar 26, 2013 5:54 pm ]
Post subject:  Extending the OSD SPI protocol

I've been hacking a little on the Minimig core for the MiST board, and I'm getting to the point where I need to extend the SPI protocol used by the OSD. (For the Chameleon and C3 cores I sidestepped this and used separate configuration signals going directly from the OSD CPU to the main CPU wrapper for the new options. That won't work for the MiST since the OSD CPU is a separate device, not part of the core.)

The original protocol was as follows:
Code:
// 8'b00000000    NOP
// 8'b001H0NNN    write data to osd buffer line <NNN> (H - highlight)
// 8'b0100--KE   enable OSD display (E) and disable Amiga keyboard (K)
// 8'b1000000B   reset Minimig (B - reset to bootloader)
// 8'b100001AA   set autofire rate
// 8'b1001---S   set cpu speed
// 8'b1010--SS   set scanline mode
// 8'b1011-SMC   set hard disk config (C - enable HDC, M - enable Master HDD, S - enable Slave HDD)
// 8'b1100FF-S   set floppy speed and drive number
// 8'b1101-EAN   set chipset features (N - ntsc, A - OCS A1000, E - ECS)
// 8'b1110HHLL   set interpolation filter (H - Hires, L - Lores)
// 8'b1111SSCC   set memory configuration (S - Slow, C - Chip)


The DE1 and Chameleon ports extended this a little, redefining the memory configuration command, like so:
Code:
// 8'b111100CC  set memory configuration (S - Slow, C - Chip, F - Fast)
// 8'b111101SS  set memory configuration (S - Slow, C - Chip, F - Fast)
// 8'b111110FF  set memory configuration (S - Slow, C - Chip, F - Fast)
// 8'b111111TT  set cpu type TT=00-68000, 01-68010, 11-68020


For the Chameleon and C3 cores I've added the following extensions:
Code:
// 8'b011RrGgB AMR extension, RrGgB OSD background colour.
// 8'b1010IISS  set scanline mode  -- II=mode when interlaced, SS=mode when non-laced.



For the MiST board, I need to add some extra bits, as follows:
* one extra bit for Fast RAM configuration (since we can support up to 24 meg of FAST RAM)
* one bit for Turbo ChipRAM (allowing Chip RAM to be read at Fast RAM speeds)
* one bit for PLL speed (we can flip on the fly between 7.09 and 8MHz base clock, bringing the video within displayable range for many otherwise stubborn monitors.)

Does anyone have any suggestions as to how the protocol should be extended, or other features in mind that will ultimately need more configuration bits? (I'm keen to do this in a way that won't cause problems with code-sharing, and hopefully ultimately unifying the OSD codebase between the various Minimig variants.)

We currently have 8'b10001xxx and 8'b000XXXXX spare, so only 8 spare bits. Is this going to be enough, or would it be better to introduce some kind of option page system?

Thoughts, anyone?

Author:  chaos [ Wed Mar 27, 2013 6:53 am ]
Post subject:  Re: Extending the OSD SPI protocol

Excellent timing! :)

I'm working on some changes around the OSD, too. I believe it's best to extend the protocol to a proper address/data protocol - that means a 16 bit transfer, with 8 bit register address and 8 bit register data. I think that would be much easier to deal with, plus it gives us a bigger register space for future expansions.

I think that at this point it is wise to make the OSD protocol compatible with multiple cores, not so minimig specific. So I'm adding the option of accessing core memory space through it (for uploading ROMs etc), instead of through the floppy interface. In the case of minimig, this also eliminates the need for a special boot ROM.

Another thing we might like to add is a core ID register, or more importantly, core version register, since the control CPU already knows which core has been loaded :)

I'd also like to extend the size of the OSD display and change the font implementation to horizontal.

Quote:
one bit for PLL speed (we can flip on the fly between 7.09 and 8MHz base clock, bringing the video within displayable range for many otherwise stubborn monitors.)

Maybe we should extend this and add a real "turbo" minimig option?

Author:  MMrobinsonb5 [ Wed Mar 27, 2013 12:33 pm ]
Post subject:  Re: Extending the OSD SPI protocol

chaos wrote:
Excellent timing! :)

I'm working on some changes around the OSD, too. I believe it's best to extend the protocol to a proper address/data protocol - that means a 16 bit transfer, with 8 bit register address and 8 bit register data. I think that would be much easier to deal with, plus it gives us a bigger register space for future expansions.


Yup, sounds good to me. I don't think backwards compatibility need be too much of a concern; upgrading the firmware on the ARM-based boards isn't too onerous a task.

Quote:
I think that at this point it is wise to make the OSD protocol compatible with multiple cores, not so minimig specific. So I'm adding the option of accessing core memory space through it (for uploading ROMs etc), instead of through the floppy interface. In the case of minimig, this also eliminates the need for a special boot ROM.


Again sounds good. (master_of_gizmo already added something similar for the Atari core, by the way, but through a different SPI channel that also carries keyboard and mouse events.)

Eliminating the boot ROM could be useful on the original Minimig since it should free up a BlockRAM - I think there's only one spare in the current build.

Quote:
Another thing we might like to add is a core ID register, or more importantly, core version register, since the control CPU already knows which core has been loaded :)


Yes, again a very good idea.

Quote:
I'd also like to extend the size of the OSD display and change the font implementation to horizontal.


Yes, the vertical OSD format caused me some head-scratching!

Quote:
Maybe we should extend this and add a real "turbo" minimig option?


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.


@Boing4000: if we get this working well for the TG68-based Minimig cores, would you be interested in adopting it for the "classic" Minimig?

@minimig_emu: any particular features that would make life easier for your alternative cores?

Author:  boing4000 [ Wed Mar 27, 2013 3:23 pm ]
Post subject:  Re: Extending the OSD SPI protocol

MMrobinsonb5 wrote:
Eliminating the boot ROM could be useful on the original Minimig since it should free up a BlockRAM - I think there's only one spare in the current build.


Question for me is, how to get the Kickstart into S-RAM?

MMrobinsonb5 wrote:
@Boing4000: if we get this working well for the TG68-based Minimig cores, would you be interested in adopting it for the "classic" Minimig?


Im not sure.
Such kind of changes is a big deal to me and I am not familiar with SPI by now.
ARM firmware must be handled by someone else.

Author:  gaula92 [ Wed Mar 27, 2013 5:44 pm ]
Post subject:  Re: Extending the OSD SPI protocol

Quote:
Im not sure.
Such kind of changes is a big deal to me and I am not familiar with SPI by now.
ARM firmware must be handled by someone else.


Ok, let's see: @chaos: would you accept a hardware donation? I'm willing to send you a new Minimig board so you can port the ARM changes and extensions, for the advancement and glory of the Minimig V1.1 board. Would you accept the donation? I would only donate the Minimig board itself: you'd have to get the ARM controller on your own as I don't have any spare ARM controllers.

In no way would it mean that I hope for any improvements or results. It would be a donation free of compromise, as I did with Mmrobinsonb5.

Author:  chaos [ Wed Mar 27, 2013 7:30 pm ]
Post subject:  Re: Extending the OSD SPI protocol

gaula92: your offer is most generous, thank you. I'd be happy to accept it and work on the original minimig :)

Author:  gaula92 [ Wed Mar 27, 2013 9:35 pm ]
Post subject:  Re: Extending the OSD SPI protocol

@chaos: let's arrange it via pm then :)

Author:  MMrobinsonb5 [ Fri Mar 29, 2013 4:46 pm ]
Post subject:  Re: Extending the OSD SPI protocol

On closer examination, it appears that the CPU speed command defined in the comments of userio.v isn't actually used at all.
instead, the turbo function is in fact folded into the Chipset Features command, whose bit interpretation is not, as the comments claim 8'b1101-EAN, but 8'b1101EANT.

Author:  minimig_emu [ Sat Mar 30, 2013 10:26 am ]
Post subject:  Re: Extending the OSD SPI protocol

Here is my modified source code for ARM firmware (Minimig board). This version works quite well but I'll be glad when it takes someone more experienced. It needs a little fine-tuning.

Attachment:
ARM_firmware.zip [325.78 KiB]
Downloaded 169 times

This is not the official version, so it is up to the discretion of each individual whether it will be use or not.

Author:  MMrobinsonb5 [ Sat Mar 30, 2013 3:00 pm ]
Post subject:  Re: Extending the OSD SPI protocol

minimig_emu wrote:
Here is my modified source code for ARM firmware (Minimig board). This version works quite well but I'll be glad when it takes someone more experienced. It needs a little fine-tuning.


Thanks for that - I've just successfully built and flashed it, but won't have time to test the alternative cores functionality until later.

I did have to make a couple of tweaks to get it to build with stock GCC. (Are you using Yagarto?)
An updated Makefile and syscalls.c file are attached. With these changes, the firmware can be built using an unmodified GCC cross-compilation toolchain, as described on my blog: http://retroramblings.net/?p=315
Also the hardcoded library path is no longer needed, since linking is now done with the gcc frontend, not using ld directly.
Also a couple of tweaks to the linker script and flash_sam_i_am files - I'm not sure how important they are.
(I can't take credit for these fixes - they're from the MiST project, but equally applicable here, since it's exactly the same ARM ┬ÁC.)

(I hope it goes without saying that, being posted in the Development section, this stuff is experimental.)

Attachments:
ARM_firmware_fixes.zip [7.27 KiB]
Downloaded 152 times

Page 1 of 3 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/