English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware

 
 
Thread Tools
Old 06 September 2018, 14:11   #1
PR77
Registered User

 
Join Date: Oct 2017
Location: Germany
Posts: 146
Kickstart ROM Address Range(s)

The Amiga Kickstart ROM (let's assume A500 OCS/ECS with 512K only initially) is physically resident at base address 0xF80000 and memory read cycles to this base address decode to the /ROMCS. Additionally, memory read cycles to base address 0xE00000 also decode to the /ROMCS (as the GARY supports 1 Meg ROM with the "other" half based at 0xE00000).


So my question, with 512K Kickstarts is base address 0xF00000 still reserved for ROM extensions? Does something similar to this exist?

Code:
FC00E2  lea      FC0000(PC),A0     Load base address of ROM we're in.
FC00E6  lea      F00000,A1         Load (absolute address) F00000.
FC00EC  cmp.l    A1,A0             Are we at F00000?
FC00EE  beq.s    FC00FE            If so, don't execute the following.
FC00F0  lea      FC00FE(PC),A5     This is relative, i.e. always points 12 bytes down from where we are.
FC00F4  cmp.w    #$1111,(A1)       If "1111" not found at F00000, then
FC00F8  bne.s    FC00FE            continue running below, else start
FC00FA  jmp      2(A1)             running at F00002.

I'm asking because I have the idea to make a CPU relocated board (yep another one ) with a small CPLD and a couple of FLASH chips to give the ability of flashing different KS versions while still having the original KS fitted. I want to avoid a multi board solution by simply suppressing the /MOTHERBOARD_AS when accessing the FLASH KS but in order to make the FLASH programmable I need the EXISTING KS to function and a place in memory to map the FLASH chips.

EDIT: I don't want to use the ZII or 0xCXXXXX space as devices might be there. But, if this can't be avoided, one option would be to allocate a 512K ZII space (not linked to the free memory pool) when a PROGRAM jumper / register is set. This would make the CPLD more complex (but still do-able nevertheless).

Sure there are commercial options available (multi board solutions though), but I want my retro computer tinkerings to be Open Source!

Last edited by PR77; 06 September 2018 at 16:58. Reason: Added some stuff
PR77 is offline  
Old 06 September 2018, 15:35   #2
RedskullDC
Digital Corruption
RedskullDC's Avatar
 
Join Date: Jan 2007
Location: Sydney/Australia
Age: 55
Posts: 320
Check out:

http://aminet.net/docs/hard/DC-KF500.lha

You're welcome

Red
RedskullDC is offline  
Old 06 September 2018, 15:37   #3
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 819
As far as I can find, All amigas has this reserved as extended rom space - on cdtv and cd32 (parts of) it is in use. If all kickstarts also boot into it is different question.
hooverphonique is offline  
Old 06 September 2018, 16:13   #4
PR77
Registered User

 
Join Date: Oct 2017
Location: Germany
Posts: 146
Quote:
Originally Posted by RedskullDC View Post
Check out:

http://aminet.net/docs/hard/DC-KF500.lha

You're welcome

Red

Thanks, I'm aware of this design. I would like though with my design to avoid switches and jumper'ing out the KS ROM. The design though doesn't answer my original question.
PR77 is offline  
Old 06 September 2018, 17:14   #5
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,363
Yes, there is support for $F00000 ROM extension in every kickstart.

How about supporting Gayle systems? (2MB ROM, second MB at $A80000)
ross is offline  
Old 06 September 2018, 19:59   #6
PR77
Registered User

 
Join Date: Oct 2017
Location: Germany
Posts: 146
Quote:
Originally Posted by ross View Post
Yes, there is support for $F00000 ROM extension in every kickstart.

How about supporting Gayle systems? (2MB ROM, second MB at $A80000)
Thanks. Gayle systems are completely out of scope here; at least for the time being. Once I have a design it will be published on GitHub so someone could extend to support Gayle systems.
PR77 is offline  
Old 06 September 2018, 20:03   #7
PR77
Registered User

 
Join Date: Oct 2017
Location: Germany
Posts: 146
The more I think about it, the more I'm leaning towards the ZII space solution. The FLASH will only occupy ZII space when in a programming session. This would be active either by a physical jumper or CPLD register followed by a reset. When in programming session, on socketed kickstart would be used to run the refreshing application.

I could be smart and actually ping-pong two 512K segments of FLASH... Now I'm just getting ahead of myself.
PR77 is offline  
Old 07 September 2018, 19:14   #8
RedskullDC
Digital Corruption
RedskullDC's Avatar
 
Join Date: Jan 2007
Location: Sydney/Australia
Age: 55
Posts: 320
Hi PR77,


Quote:
Originally Posted by PR77 View Post


>>So my question, with 512K Kickstarts is base address 0xF00000 still reserved for ROM extensions? Does something similar to this exist?


Thanks, I'm aware of this design. I would like though with my design to avoid switches and jumper'ing out the KS ROM. The design though doesn't answer my original question.

It does answer your question actually.


Read the docs.


$E00000-$E7FFFF is used for writing to the flash.
Kickstart stays enabled at $F80000-$FFFFFF.




Red
RedskullDC is offline  
Old 07 September 2018, 19:43   #9
thebajaguy
Registered User

 
Join Date: Mar 2017
Location: Philadelphia / United States
Posts: 46
This might work with the OS up, and be friendly enough, though there is some complexity.

I would suggest staying clear of F80000 and E00000 for any writing. I think Gary may terminate writes to the ROM areas (in some or all implementations).

Also, ff these areas are going to be tinkered with when the OS up (even if a reset will happen soon after / no return to the OS) an MMU table may define the known ROM areas as Read Only, and terminate any write attempts (for efficiency, if not for an Enforcer or MUForce/MUGA hit). Different 680x0 libraries may even lock down some other unused parts of the areas above the 8M Z2 expansion space, so keep it in the back of the mind - most of the area above 8M space (A00000+) is ROM or I/O registers.

I suggest going for the 2nd half of the 2MB ROMY Kickstart address range solution for writes - I think the 1M range is A80000-B7FFFF - treat it as two 512K segments just like F8 and E0. Check the address range just to be sure on the threads discussing ROMY and matching Kickstart remap tools here on EAB.

I would also suggest putting a read-only register (or three) above F00000, maybe at the 128K or 256K address point offset. Read bits in the first indicate which bank you have in place, and the r/w state of the bank(s). Another register read will toggle r/w on the live 512K bank, and another register read toggles the banks between segments of your flash ROM.

Hint: Offset the registers by 4 longwords (or let them be 32-bit duplicates within the 16-byte/4 longword space) at minimum. A 68040/68060 may read 4 longwords if the on-board accelerator card logic can't/doesn't terminate a cache burst fill - this prevents errant register behavior. This stuff is in some lessons learned in the 1990's Zorro III PIC design notes - not a new idea, but not well known outside of HW developers.

I also suggested the toggle state on read so a write doesn't cause an unexpected bus error the system might not handle well, and it's more MMU-friendly if a table is set up by an unknown library.

The reason for skipping the use of the base of F00000 space is because classic-era 68060 boards used this space to put a few dozen bytes of code in during startup to tame the 68060 FPU. Hacked Kickstart after 3.1 also have that code soon after the F00000 ROM check for the 040-060 adapter upgraded boards (so not needed, but it's there on the classic boards). Ref: Take a look at a P5 A2000 68060 board, or the TekMagic 2060, or any 1990's 68060 board for the 32-bit systems. You will find an expansion.library entry for a 512K F00000 board when they have that littel bit of ROM code present. I have a TekMagic 68060 (ultrasound), which is a relative of the TekMagic/GVP TRex-II 68060 board, and it has it.

Good luck!
thebajaguy is offline  
Old 07 September 2018, 19:47   #10
thebajaguy
Registered User

 
Join Date: Mar 2017
Location: Philadelphia / United States
Posts: 46
Also, by putting all write activity lower down at A80000-B7FFFF, one could cycle 1M Kickstart in to F8/E0.

Putting your own misc code into the upper half of the F00000-F7FFFF range also gives you plenty of handling code space if you are putting the OS aside, and it won't affect anything just by sitting there.
thebajaguy is offline  
Old 07 September 2018, 20:15   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,116
Why not make it Z2 IO board and not map the flash 1:1 when writing? (Banking, some other method, it does not need to be fast, space for other IO bits if needed) Guaranteed no conflicts.
Toni Wilen is offline  
Old 07 September 2018, 22:00   #12
PR77
Registered User

 
Join Date: Oct 2017
Location: Germany
Posts: 146
Quote:
Originally Posted by Toni Wilen View Post
Why not make it Z2 IO board and not map the flash 1:1 when writing? (Banking, some other method, it does not need to be fast, space for other IO bits if needed) Guaranteed no conflicts.
Agree, that's is my plan now. Always wise and constructive feedback Toni! At least the 512K should Autoconfig outside of the free memory pool based at 0x20000 (I will double check my 68SEC000 accelerator where I have 512K mapped for SPI FLASH [which I will remove because I think it is not very useful on the next revision]).

I started with the schematic yesterday and routed the signals for Autoconfig. Additionally I added the E CLK input so theoretically I could use that to time how long RESET is asserted for to allow for a jumper-less solution when switching into a programming session.

I.e., ON NEG-EDGE RESET, while /RESET count 700K E cycles (else count = 0). When 700K cycles has been counted bypass FLASH and boot from existing Kickstart + map FLASH in Z2 space for programming. Simple, huh?!?
PR77 is offline  
Old 07 September 2018, 22:13   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,116
Z2 RAM space is not imho good idea because 8M RAM expansions aren't that rare (for example HD controller with RAM expansion). Thats why I recommended using IO space. (which needs some kind of banking because 512k is too large for IO)

Some other nice to have features: if flash is large enough for multiple ROM images, some kind of boot selector would be really nice (=one "bank" has boot selector code instead of KS ROM image), software based ROM selection is always better than jumpers
Toni Wilen is offline  
Old 07 September 2018, 23:14   #14
PR77
Registered User

 
Join Date: Oct 2017
Location: Germany
Posts: 146
Quote:
Originally Posted by Toni Wilen View Post
Some other nice to have features: if flash is large enough for multiple ROM images, some kind of boot selector would be really nice (=one "bank" has boot selector code instead of KS ROM image), software based ROM selection is always better than jumpers
Nice idea. Baby steps first; I see no reason that the design could not support it from a capability point of view; the Z2 config could support a Vector to a DiagArea block. This is how the ACA500+ and the HC508 work I believe.
PR77 is offline  
Old 08 September 2018, 10:33   #15
PR77
Registered User

 
Join Date: Oct 2017
Location: Germany
Posts: 146
Quote:
Originally Posted by thebajaguy View Post
This might work with the OS up, and be friendly enough, though there is some complexity.

I would suggest staying clear of F80000 and E00000 for any writing. I think Gary may terminate writes to the ROM areas (in some or all implementations).

Also, ff these areas are going to be tinkered with when the OS up (even if a reset will happen soon after / no return to the OS) an MMU table may define the known ROM areas as Read Only, and terminate any write attempts (for efficiency, if not for an Enforcer or MUForce/MUGA hit). Different 680x0 libraries may even lock down some other unused parts of the areas above the 8M Z2 expansion space, so keep it in the back of the mind - most of the area above 8M space (A00000+) is ROM or I/O registers.

I suggest going for the 2nd half of the 2MB ROMY Kickstart address range solution for writes - I think the 1M range is A80000-B7FFFF - treat it as two 512K segments just like F8 and E0. Check the address range just to be sure on the threads discussing ROMY and matching Kickstart remap tools here on EAB.

I would also suggest putting a read-only register (or three) above F00000, maybe at the 128K or 256K address point offset. Read bits in the first indicate which bank you have in place, and the r/w state of the bank(s). Another register read will toggle r/w on the live 512K bank, and another register read toggles the banks between segments of your flash ROM.

Hint: Offset the registers by 4 longwords (or let them be 32-bit duplicates within the 16-byte/4 longword space) at minimum. A 68040/68060 may read 4 longwords if the on-board accelerator card logic can't/doesn't terminate a cache burst fill - this prevents errant register behavior. This stuff is in some lessons learned in the 1990's Zorro III PIC design notes - not a new idea, but not well known outside of HW developers.

I also suggested the toggle state on read so a write doesn't cause an unexpected bus error the system might not handle well, and it's more MMU-friendly if a table is set up by an unknown library.

The reason for skipping the use of the base of F00000 space is because classic-era 68060 boards used this space to put a few dozen bytes of code in during startup to tame the 68060 FPU. Hacked Kickstart after 3.1 also have that code soon after the F00000 ROM check for the 040-060 adapter upgraded boards (so not needed, but it's there on the classic boards). Ref: Take a look at a P5 A2000 68060 board, or the TekMagic 2060, or any 1990's 68060 board for the 32-bit systems. You will find an expansion.library entry for a 512K F00000 board when they have that littel bit of ROM code present. I have a TekMagic 68060 (ultrasound), which is a relative of the TekMagic/GVP TRex-II 68060 board, and it has it.

Good luck!
Thanks for all this great info. I was a bit overwhelmed with the details to be honest. Have you designed accelerators / CPU cards? There is some fairly details points there. Given I will use Z2 space it is the simplest for me. Support for 040s and 060s is something I'll let the community ponder once I put the stuff up on Github. Hopefully this will be done by the end of the weekend. Not to sure about the PCB routing as this is not my strong point.
PR77 is offline  
Old 09 September 2018, 01:14   #16
PR77
Registered User

 
Join Date: Oct 2017
Location: Germany
Posts: 146
https://github.com/PR77/68000_Relocator_FLASH_Kickstart
PR77 is offline  
Old 09 September 2018, 03:47   #17
thebajaguy
Registered User

 
Join Date: Mar 2017
Location: Philadelphia / United States
Posts: 46
My background is working for GVP Tech Support back in 89-93 (I was employee #9. SCSI, RAM, serial, and accelerators was my area of expertise. I'm also a current beta tester for Amiga OS 3.1.4. I'm beating on AutoConfig, 68030/040/060 CPUs, and other related things. I'm actually re-learning stuff I used to know 25 years ago, plus uncovering some darkness-loving critters, and helping squish them.

The stuff I outlined is from lessons learned. Tony up there is correct - you don't want to insert something into $200000-9FFFFF, unless it's a legal AutoConfig board. Aasking for 512K in the 8M space via AutoConfig protocol is legal - the A2091 can do that with RAM, but I sense you are going to 'get it working' first. You also don't want to shove a ROM R/W image into the I/O space (E80000-EFFFFF) without being system friendly. The problem is that while it is 512K of space, boards will appear there, and the OS will configure them on 64K and 128K boundaries.

If you are going legal: I know that I/O AutoConfig space (E80000-EFFFFF) supports 64K and 128K PICs. It might support 256K, but I don't advise going that large - it can fill up fast that way. Build yourself a 64K PIC, make 1/2 of it control registers, and the other 1/2 (32K) a rotatable window to your programmable ROM space of choice. You then program them at 32K at a time, rotating the window with a read or write of your control register. It's possible to trick the window on a write to the last byte/word/longword to rotate to the next window, but that's for you to design, if you want to.

As I wrote above, if you are going to brute-force it into the memory map for the first round, and if you are aiming for the Z2 memory map on classic 68K systems, give the 10MB address point ($00a00000) a try. Z2 big memory (8M) space is $00200000 - assuming you were thinking of there. Just one additional address line (the 8M line) to decode with the $00200000 puts you at $00A00000. The A500/1000/2000 doesn't have anything up there. The only pitfall is the A600 has PCMCIA registers in that 512K space. The A80000-AFFFFF or B00000-B7FFFF is safe on all classic 68K systems, and unless someone is already playing with 2MB Kickstart, the 32-bit systems are otherwise clear up in that space.

Here is a memory map reference: https://www.amigacoding.com/index.php/Amiga_memory_map

Another 'safer' 512K space is $D00000-D7FFFF - the only possible conflicts with this are the Insider 1000 and similar classic A1000 1.5MB FastRAM boards that went into the CPU socket.

As for 68040/68060 and spacing out your registers - I was mainly suggesting a best practice for handling I/O with these chips that offers the best compatibility. A 68040 or a 68060 on an A2000 is not uncommon. I have 3 68040 boards for the A2000, and I've put a 68060 adapter on one of them and had it running.

Good luck!
thebajaguy is offline  
Old 09 September 2018, 03:55   #18
thebajaguy
Registered User

 
Join Date: Mar 2017
Location: Philadelphia / United States
Posts: 46
Oh, and PCB routing is not my forte, either. I wish I could dig into it.

Also, here is the (very long read - save for the morning/beverage time) detail on Zorro III, 68030/68040/68060 and the expansion challenges.

http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node0161.html

It's written by Michael Sinz. He kinda knows what he was talking about being from C= in the Amiga engineering department.

Last edited by thebajaguy; 09 September 2018 at 04:58.
thebajaguy is offline  
Old 09 September 2018, 12:35   #19
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,363
Quote:
Originally Posted by thebajaguy View Post
Another 'safer' 512K space is $D00000-D7FFFF - the only possible conflicts with this are the Insider 1000 and similar classic A1000 1.5MB FastRAM boards that went into the CPU socket.
Actually is not so safe.
I remember back on the days that existed various expansion for the A500 that go up from $C00000 to $D7FFFF [1.5MB] (even someone to $DBFFFF [1.75MB]).
And these expansions are perfectly legal and autoconfigured, there is code on KS that scan this area in 256KB increment (up to the area of Battery backed up clock at $DC0000).
ross is offline  
Old 09 September 2018, 14:24   #20
Docy
Registered User

 
Join Date: Aug 2018
Location: here
Posts: 2
Quote:
Originally Posted by PR77 View Post
I'm asking because I have the idea to make a CPU relocated board (yep another one ) with a small CPLD and a couple of FLASH chips to give the ability of flashing different KS versions while still having the original KS fitted.
Except having the original kickstart chip *not* fitted after inital flashing you may find this useful: http://www.amigawiki.de/doku.php?id=...kickflash_a500

It works perfect with A500/A2000 and even a CDTV is possible with option to flash the Boot-ROMs there. No jumpers no soldering necessary.
I can hold up to four 512 kB Kickstart images.
Docy is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Kickstart 1.3 ROM earok Coders. Blitz Basic 13 15 March 2017 14:08
Overzealous Kickstart ROM - address decoding? robinsonb5 Hardware mods 3 30 June 2013 12:09
CD32 kickstart rom & extended rom ben111g Amiga scene 1 24 February 2007 14:56
Kickstart 2.04 ROM crs MarketPlace 19 19 December 2006 13:44
Kickstart ROM Toxic support.WinUAE 7 08 November 2001 22:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 02:22.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09263 seconds with 13 queries