I added the first release code to the first post. Comments are welcome. If anyone wants to test this I have a couple of extra boards and for a small fee you also get the SRAMs (512kx8) and a FLASH AM29F040.
As soon as I'm satisfied with the code I'll post it to the OBEX.
> H
Here is Pacito's propBDM interface v1.05
The processor is in HALT state (LED should light-up)
Commands (addresses and values in HEX):
D <addr>: Dump memory (LONG)
G : executes the BDM GO command and exits HALT state
H : This help screen
RB <addr>: Read byte
RC <Ctrl Reg> : Read Control Register (Name)
RD : Register Dump
RE : Resets the processor and re-enters HALT state
RL <addr>: Read Long
RW <addr>: Read Word
WB <addr> <value>: write byte
WC <Ctrl reg> <value>: Writes Control register (NAME) (32 bits)
WR <reg> <value>: Write register (D0..7 or A0..7) (32 bits)
WW <addr> <value>: Write word
WL <addr> <value>: Write long
Have fun
> WC MBAR 1
MBAR: 00000001
> WL 74F00JJ
Too few arguments
> WL 74 F000003E
> WC RAMBAR 10001
RAMBAR: 00010001
> D 10000
Dumping at adress: 00010000
00010000 BE BA 00 00 8D E9 1C BA 12 0C 1D 60 6C D0 55 44 `l UD
00010010 9E AF 8B C2 2C 4A AB 32 F1 36 13 F6 7E D7 EA 36 ,J 2 6 ~ 6
00010020 49 B5 A9 F4 1C 0A BF 4E 7E 05 D9 68 A3 7F 29 F8 I N~ h ?)
00010030 BF 65 E4 C0 02 B4 B8 96 2E DB AD CE A1 03 F3 A5 e .
00010040 FB 6E BC DF 72 65 B1 93 6E 8D 4A 11 DC CC E3 E3 n re n J
00010050 12 67 1D D2 34 B7 21 E5 A1 8C 0B FF 14 1A 46 D5 g 4 ! F
00010060 56 FD 59 2F 60 47 D8 20 31 A7 2E B9 07 67 2E 11 V Y/`G 1 . g.
00010070 8C 89 22 D1 9D AC 2E 31 D4 F9 9E 4B D9 73 06 D0 " .1 K s
00010080 E6 E8 CF C9 FD CA A2 E2 0B CC C0 6A 6E 41 C2 B6 jnA
00010090 FA 86 AA E8 23 58 90 F4 EF DD EB CD EE 08 D8 AD #X
000100A0 71 7C AD F1 87 DA AF CA F7 32 9E 9A 14 50 CD 93 q| 2 P
000100B0 A3 6C 04 AE F7 A8 BA BC EE 4B F2 8C BA 49 24 5E l K I$^
000100C0 74 C8 A5 ED 8B 9D 94 C5 ED 05 39 C2 98 29 E8 48 t 9 ) H
000100D0 BD EA E1 B1 62 0A CE 9A EB 0D 0F 20 1B 54 A4 E5 b T
000100E0 3C EE C7 FD 7F 6A 6C 2C 7D 0A 8F 8C 76 DE 92 F9 < ?jl,} v
000100F0 5A CF 3A BC 91 6B 82 6F BA B2 B9 6B 66 C4 C8 D1 Z : k o kf
>
I think that I am going to use a v1 ColdFire with out eMAC as I keep running into a wall with the A-Line instructions. Besides I do intend to use a Propeller II as soon as available to emulate a XC68040 at 60MIPS (yes I think it can be done), maybe a little more if the Prop2 will overclock well (hopefully to 200MHz+).
what do you mean with "running into a wall" ? are you using the right ISA for your device ?
I am trying to bootstrap the board using BDM. Initialization of
MBAR/CACR and internal SRAM works well, I can read/write the internal
SRAM.
When I try to initialize CS0 so I can access the FLASH, reading the
FLASH hangs (the read operation never completes and CSO is never
asserted).
I tried Motorola's examples, the CFInit utility also without luck.
Just an example (taken from the CFInit utility) :
what do you mean with "running into a wall" ? are you using the right ISA for your device ?
CF is not ideal, though with handling the addressing and illegal op traps 99.7% of all 680x0 software runs with no problems, and no original 680x0 can match the speed, it is that 0.3% that is causing me difficulty.
I am going to build a second board and see how it behaves... maybe this CF is somewhat shot...
I found a soft emulator for 68k on the CF...in this site http://turbo-cf.narod.ru/eng/download.html have you tested it ? Which instructions are causing problems ?
It just occurred to me that maybe just maybe one or more power pins are not making contact with the board. I'll have to check them all just in case they power the chip separately instead of connecting to a power ring. (The voltage was tested and measured 3.278 V). The readout of CACR still bugs me...I'll test with other values too.
Yes I have. The instructions causing the trouble are the A-Line traps (opcodes $A000 through $AFFF), which the CF has mapped to the eMAC instructions, as such there is no way to trap them as illegal. I have heard that there is a way to disable the eMAC (thus making the A-Line ops behave), but I can not figure it out.
I thought I read about disabling the eMAC somewhere... I just read the CFPRM and the 5407 manuals but discovered nothing of the sort... and those line A opcodes where used as traps... weren't they ? ...
Yes they were. Almost all 68k systems used the Line-A ops as traps, although they were not used by the OS on the Amiga, some applications & shared libs took advantage of them.
The Coldfire works, I let it run without the BKPT line and CS0 toggles at half the clock speed... it should have 15 wait states (I read the configuration back and it was correct)... that means that something does not work with the BDM (and the autogeneration of TA). I'll try programming the Flash from SRAM. I am really glad that programming the propeller is a breeze... if it only had more IOs....
Edit: I left TA floating because I thought I'd only use autogenerated TA and ATA... I'll pull TA up and see how it behaves
I built a second board and... it behaves exactly like the first one. The problem is it does not seem to exit the RESET state when RESET is pulled high.
Using the BDM I initialize the internal SRAM and exit the HALT state via the GO command and negating BKPT (goes high), a new value for A7 is loaded from SRAM but the new PC is never loaded, the processor seems to hang! (there is a steady CLK of 5 MHz). I'm completely at a loss here as to what exactly is going on. The 68020 seems so easy in comparison... I'll have to dig a bit more.
With regard to the TA line, I pulled-up and now after exiting RESET CS0 does not toggle anymore, very strange
Ale:
I do not know what your use is for the CF. Though have you thought about using a CPU32 instead? The instruction set is very simular (the CPU32 being an original 68K) and the speed is comparable to the CF that you are playing with. If you do not need any of the extra custom peripherials of the CF this may be the way to go.
I actually need something with 1 MB RAM and 50 or more MIPS. I do not care what the architecture is. I think I'll reconsider the ARM and the AVR32. Sad that I wasted so much time and money in this CF borad I had so hope...
Ale:
It is always sad to waste time, and money. As I had done trying to use the CF for my project, for me it was the CFs use of the Line-A opcodes that sent me away from the CF.
On a different note I have been working on a 68K emulator for the Prop II, that should exceed 50MIPS. This is useful as the real 68K CPUs are no longer produced (excepting the 68SEC000, and CPU32). I do not know if you use assembly or not, though it is widely agreed that the 68K series assembly is one of the easiest to work with.
I love 68K assembly, I programmed quite a bit in it. I'll resuscitate this pPropQL020 board (68EC020 based) and see if I can get it to work (the >50 MIPS project is for something else)
I think I know why it does not work as it should. Re-reading the manual, signal description section, I come across the Bus Grant signal. It is contrary to the 020 an INPUT!. I pulled-up Bus Request thinking that it was the input from an external device, I see now my error... I'll pull it up (*BG) and see what happens...
Edit: Re-reading the manual again, I see that BG grants the Coldfire the use of the BUS, and thus this signal has to be pulled low, and not high as I wrote before.
Ale:
I do not know if it is of any interest for your projects or not, though:
I have overclocked the 68EC000 20MHz part to 48MHz stable, and the 68SEC000 16MHz part to 80MHz stable. I have not tried anything higher than 80MHz, though that is still fairly quick if your code is well optimized and you have fast enough SRAM to ground out DTACK. Though if you have to communicate with a Propeller you probably do not want to ground DTACK as you will need wait states for that, you can always ground DTACK unless the two high address lines go high, then use wait states to read the address and data lines with the Propeller (Thus I do).
Those are pretty solid overclocks !! I was thinking of overclocking the EC020 (16 MHz part) to 20 or 25 to see if it works, I may still do it . The SEC000 can still be bought for a reasonable price. I replaced the propellers with a FPGA because I needed a bit more than what a propeller provides. The propBDM OTOH needs no replacing as it works rock-solid .
Now that I got the CF to read/write external memory (how could I forget about Bus Grant!) I'll continue development to see if the speed is enough. I may change to another CF (5407) if I need a bit more oomph.
It just occurred to me that your problems with the Line-A opcodes could be worked-around by patching the software. The OS has been written already thus it is a matter of identifying those traps and changing them to some other unused opcode (I really do not know how they coded the function in the invalid opcode), it may work, you also may have already thought of it .
Ale:
I thank you, though the Line-A stuff in the Coldfire is hard coded and thus does not produce an exception, this is one of the first things I tried.
On overclocking the 68EC020 you will not be able to get past about 45MHz if you have one of the newer parts, and 30MHz will be the safe ceiling for the older parts. These are numbers that have been verified by many users, with a wide range of batches.
No one has yet reached the speed ceiling of the 68SEC000, many report running it between 70MHz and 100MHz, and no one has yet ran into the limit. Though if I were to take it past 90MHz I would add a heat sync.
The thing is that with the SEC000 you are limited by the 16 bit BUS and 4 cycles of memory access. The 020 improves it to 3 cycles and 32 bit BUS, but you know all that already. I'll try with my 020 anyday now !
So no Line-A opcodes produce an exception ? is that a V2 CF?... The V4 coldfires should trap on invalid opcode even for an unused line-A... well if the world were perfect....
Ale:
It will trap if the Line-A opcode is not used by the Coldfire MAC. The problem is that it will not trap for the Line-A ops that are used by the MAC.
Ale: It is to bad that the Coldfire does not have the FC0-FC2 lines of the earlier 68K CPUs, this could provide a good solution for the A-Line trouble if it did:
I have been playing with simulating a 68020 on the 68SEC000 including 32-bit addressing. I am doing this with a couple of Props monitoring the instruction stream (with the aid of watching for the bit pattern of either 010 or 101 on the FC pins) checking the address mode and op code class, and if required updating its copy of the address registers to match. This does also require keeping a close eye for instructions that directly modify an address register or PC. It is only partially working at this time, but I do have 32-bit addressing on the 68SEC000 (clocked at 40MHz so the Prop can keep up). The next step is to write the illegal instruction handler for the 68020 ops, and addressing modes not supported by the 68000.
That is why I suggested patching the software but before you run it. Just patch the ROM with free line-A opcodes in place of the colliding line-A opcodes (where the MAC instructions are mapped). I'm still not convinced why I wouldn't work, the other methods look more complicated and laborious.
Maybe all the software has to be patched...
Ale:
Having done a bit of research; I have found that most 68000s are able to be over clocked well beyond the clock speed of the other 68K series CPUs. This I find quite interesting, and thought you might as well. If you over clock a 68000 to 128MHz imagine the possibility ( I do not think any one has yet done this [I guess I will have to play guinea pig on this one]). See you on the FAST side of the true 68K .
Ale:
Cool.
In place of the crystal you can use a Propeller counter, if you have an extra Propeller laying around. Also because of the simplicity of the 680x0 HW it is fairly simple to make a test system with little more than a 68ec020, a Propeller, some passive components, some ram and a ROM.
EXAMPLE (For the Prop part):
Connect 020 CLK to Propeller P0.
Connect 020 A0 - A8 to Propeller P12 - P15.
Connect 020 /DSACK0 - /DSACK1 to Propeller P1 - P2.
Connect 020 FC0 - FC2 to Prop P3 - P5.
Connect 020 IOPL0 - IOPL3 to Prop P8 - P11.
Connect 020 AVEC to Prop P6.
Connect the ORed value of 020 A8 - A32 to Prop P7.
Connect 020 R/W to Prop P24.
Connect the DATA bus through a 8 74xx244 buffers (so you can access it as 8 bits wide) to Prop P16 - P23.
Wire the buffers using DSACK to control the 020 DATA bus byte connected to the Prop.
Write a simple test routine for the 68k.
Program the prop to act as a 256BYTE boot ROM, I/O device (using the remaining pins) and a interrupt controller.
This is actually fairly simple, though even simpler on the 68000. Also I would take the time to add a couple more buffers to switch from ORing the upper addresses to ANDing them after the start address is read, so as to move the ROM from the bottom of 68020 memory to the top.
Actually you have to use also SIZ0 and SIZ1 if not you can't decode the size of the transfer. All that fits in a small CPLD (see my sig because I have it already working at 16 MHz) . Yes, I can avoid the crystal using a propeller pin, there are a couple of them free
Comments
I added the first release code to the first post. Comments are welcome. If anyone wants to test this I have a couple of extra boards and for a small fee you also get the SRAMs (512kx8) and a FLASH AM29F040.
As soon as I'm satisfied with the code I'll post it to the OBEX.
Ale
I am trying to bootstrap the board using BDM. Initialization of
MBAR/CACR and internal SRAM works well, I can read/write the internal
SRAM.
When I try to initialize CS0 so I can access the FLASH, reading the
FLASH hangs (the read operation never completes and CSO is never
asserted).
I tried Motorola's examples, the CFInit utility also without luck.
Just an example (taken from the CFInit utility) :
MBAR = 00000001
CACR = 01000000
ACR0 = 0
ACR1 = 0
CSAR0 = 0008
CSCR0 = 095F
CSMR0 = 00070000
DMCR = 0100 The last read to 0x68 shows that the BDM does not answer anymore...
meaning that the read to memory did not complete (it returns 0s).
Any idea what can be wrong ?.
(The read to CACR should return 01000000 I know, I just do not know why
it does not...).
Thanks!
CF is not ideal, though with handling the addressing and illegal op traps 99.7% of all 680x0 software runs with no problems, and no original 680x0 can match the speed, it is that 0.3% that is causing me difficulty.
I found a soft emulator for 68k on the CF...in this site http://turbo-cf.narod.ru/eng/download.html have you tested it ? Which instructions are causing problems ?
Edit: I left TA floating because I thought I'd only use autogenerated TA and ATA... I'll pull TA up and see how it behaves
Using the BDM I initialize the internal SRAM and exit the HALT state via the GO command and negating BKPT (goes high), a new value for A7 is loaded from SRAM but the new PC is never loaded, the processor seems to hang! (there is a steady CLK of 5 MHz). I'm completely at a loss here as to what exactly is going on. The 68020 seems so easy in comparison... I'll have to dig a bit more.
With regard to the TA line, I pulled-up and now after exiting RESET CS0 does not toggle anymore, very strange
I do not know what your use is for the CF. Though have you thought about using a CPU32 instead? The instruction set is very simular (the CPU32 being an original 68K) and the speed is comparable to the CF that you are playing with. If you do not need any of the extra custom peripherials of the CF this may be the way to go.
It is always sad to waste time, and money. As I had done trying to use the CF for my project, for me it was the CFs use of the Line-A opcodes that sent me away from the CF.
On a different note I have been working on a 68K emulator for the Prop II, that should exceed 50MIPS. This is useful as the real 68K CPUs are no longer produced (excepting the 68SEC000, and CPU32). I do not know if you use assembly or not, though it is widely agreed that the 68K series assembly is one of the easiest to work with.
Edit: Re-reading the manual again, I see that BG grants the Coldfire the use of the BUS, and thus this signal has to be pulled low, and not high as I wrote before.
I do not know if it is of any interest for your projects or not, though:
I have overclocked the 68EC000 20MHz part to 48MHz stable, and the 68SEC000 16MHz part to 80MHz stable. I have not tried anything higher than 80MHz, though that is still fairly quick if your code is well optimized and you have fast enough SRAM to ground out DTACK. Though if you have to communicate with a Propeller you probably do not want to ground DTACK as you will need wait states for that, you can always ground DTACK unless the two high address lines go high, then use wait states to read the address and data lines with the Propeller (Thus I do).
Those are pretty solid overclocks !! I was thinking of overclocking the EC020 (16 MHz part) to 20 or 25 to see if it works, I may still do it
Now that I got the CF to read/write external memory (how could I forget about Bus Grant!) I'll continue development to see if the speed is enough. I may change to another CF (5407) if I need a bit more oomph.
It just occurred to me that your problems with the Line-A opcodes could be worked-around by patching the software. The OS has been written already thus it is a matter of identifying those traps and changing them to some other unused opcode (I really do not know how they coded the function in the invalid opcode), it may work, you also may have already thought of it
I thank you, though the Line-A stuff in the Coldfire is hard coded and thus does not produce an exception, this is one of the first things I tried.
On overclocking the 68EC020 you will not be able to get past about 45MHz if you have one of the newer parts, and 30MHz will be the safe ceiling for the older parts. These are numbers that have been verified by many users, with a wide range of batches.
No one has yet reached the speed ceiling of the 68SEC000, many report running it between 70MHz and 100MHz, and no one has yet ran into the limit. Though if I were to take it past 90MHz I would add a heat sync.
So no Line-A opcodes produce an exception ? is that a V2 CF?... The V4 coldfires should trap on invalid opcode even for an unused line-A... well if the world were perfect....
It will trap if the Line-A opcode is not used by the Coldfire MAC. The problem is that it will not trap for the Line-A ops that are used by the MAC.
It is to bad that the Coldfire does not have the FC0-FC2 lines of the earlier 68K CPUs, this could provide a good solution for the A-Line trouble if it did:
I have been playing with simulating a 68020 on the 68SEC000 including 32-bit addressing. I am doing this with a couple of Props monitoring the instruction stream (with the aid of watching for the bit pattern of either 010 or 101 on the FC pins) checking the address mode and op code class, and if required updating its copy of the address registers to match. This does also require keeping a close eye for instructions that directly modify an address register or PC. It is only partially working at this time, but I do have 32-bit addressing on the 68SEC000 (clocked at 40MHz so the Prop can keep up). The next step is to write the illegal instruction handler for the 68020 ops, and addressing modes not supported by the 68000.
Maybe all the software has to be patched...
All the software would have to be patched. Amiga OS does not use or trap Line-A it self, though many apps do.
Having done a bit of research; I have found that most 68000s are able to be over clocked well beyond the clock speed of the other 68K series CPUs. This I find quite interesting, and thought you might as well. If you over clock a 68000 to 128MHz imagine the possibility ( I do not think any one has yet done this [I guess I will have to play guinea pig on this one]). See you on the FAST side of the true 68K
Cool.
In place of the crystal you can use a Propeller counter, if you have an extra Propeller laying around. Also because of the simplicity of the 680x0 HW it is fairly simple to make a test system with little more than a 68ec020, a Propeller, some passive components, some ram and a ROM.
EXAMPLE (For the Prop part):
Connect 020 CLK to Propeller P0.
Connect 020 A0 - A8 to Propeller P12 - P15.
Connect 020 /DSACK0 - /DSACK1 to Propeller P1 - P2.
Connect 020 FC0 - FC2 to Prop P3 - P5.
Connect 020 IOPL0 - IOPL3 to Prop P8 - P11.
Connect 020 AVEC to Prop P6.
Connect the ORed value of 020 A8 - A32 to Prop P7.
Connect 020 R/W to Prop P24.
Connect the DATA bus through a 8 74xx244 buffers (so you can access it as 8 bits wide) to Prop P16 - P23.
Wire the buffers using DSACK to control the 020 DATA bus byte connected to the Prop.
Write a simple test routine for the 68k.
Program the prop to act as a 256BYTE boot ROM, I/O device (using the remaining pins) and a interrupt controller.
This is actually fairly simple, though even simpler on the 68000. Also I would take the time to add a couple more buffers to switch from ORing the upper addresses to ANDing them after the start address is read, so as to move the ROM from the bottom of 68020 memory to the top.