Open source 14MHz 68000 accelerator

[Mathesar]

More thoughts: Your trapdoor RAM board has untapped potential as only 0,5Mbyte of each 2Mbyte chip is actually used. What about mapping the untapped memory into ZORRO II space?

[PeteAU]

Originally Posted by Mathesar

You had the same idea that I had . Yes, the idea was to separate the accelerator and ram boards. And yes, the plan is to have connectors on the side... This way I can develop in phases, first a DMA compatible 14MHz cpu (maybe with SD interface), then a fast ram board. Maybe we could indeed do a dram board. I think autoconfig is also doable with just discrete logic.... No GAL's needed. I never looked into a 21MHz version but the biggest problem would probably be the E clock.

It's a neat idea, to have modular boards with a connector on the side. Maybe 2.00mm to save space? Then there could be a SRAM ranger board, SRAM auto-config board, DRAM board, or whatever people want to come up with.

A few jobs ago (oh crap, 10+ years ago) I did a little product with microcontroller and SDcard interface. Many micros come with pretty good SD and FAT16/32 libraries. But you're getting into quite a project there. Or did you mean to do the SD software on the Amiga side?

Originally Posted by Mathesar

More thoughts: Your trapdoor RAM board has untapped potential as only 0,5Mbyte of each 2Mbyte chip is actually used. What about mapping the untapped memory into ZORRO II space?

Hmmm... I left a pad for "A9" on the board, half thinking about that - but can't really imagine how - because Agnus is RAS/CASing them. Header and ribbon cable back to the CPU board?

[Mathesar]

Originally Posted by PeteAU

Hmmm... I left a pad for "A9" on the board, half thinking about that - but can't really imagine how - because Agnus is RAS/CASing them. Header and ribbon cable back to the CPU board?

You can just expand your trick to map 512K blocks into the Amiga's memory space. But instead of mapping the 512K blocks to $C00000, map them to $200000. Getting the full 2Mbyte out of the DRAM chips is tricky because of the refresh (it can be done but not with a few simple discrete chips), so we are stuck with 512 rows but we can address 1024 columns by using A9 together with ~CAS. This way we can double the amount of memory we get out of the 4 dram chips. It won't be real (as in "fast") fastram but it will be cheap!

[Mathesar]

Originally Posted by PeteAU

Many micros come with pretty good SD and FAT16/32 libraries. But you're getting into quite a project there. Or did you mean to do the SD software on the Amiga side?

It's not too difficult, I have Mika's "A500ide" running here which uses the a simple device driver written in assembly. That driver can be modified to talk to an SD card instead of an IDE device. As long as the driver allows reading and writing of 512 byte sectors it will work. (Oh and we need to fake some sector/cylinder/surfaces thing for HDtoolbox to work).
And there are other open source drivers out there as well, including SD card drivers. But again, to stay in the spirit of easy DIY-able designs, it will be a pretty simple hardware interface so it will be relatively slow.

[PeteAU]

Originally Posted by Mathesar

It's not too difficult, I have Mika's "A500ide" running here which uses the a simple device driver written in assembly. That driver can be modified to talk to an SD card instead of an IDE device. As long as the driver allows reading and writing of 512 byte sectors it will work. (Oh and we need to fake some sector/cylinder/surfaces thing for HDtoolbox to work).
And there are other open source drivers out there as well, including SD card drivers. But again, to stay in the spirit of easy DIY-able designs, it will be a pretty simple hardware interface so it will be relatively slow.

It does sound good. Super simple hardware and save the complexity for the drivers. A little faster than a floppy is good enough IMO.

Maybe people would enjoy a simple microSD card interface added to your existing design. It would be the simplest accel/ram/hdd card out there. I'd build one up.

[utri007]

Originally Posted by Mathesar

That is very low. I need to check my old measurements to come up with a different resistor value for the PLL. The low value of 1.6V means that the dutycycle of the clock is not 50%. This influences the timing and may thus be a reason that it does not work well with the IDE68K.

My friend did some desoldering and now it shows 2,7v. MKL's IDE still not working.

[Mathesar]

Originally Posted by utri007

My friend did some desoldering and now it shows 2,7v. MKL's IDE still not working.

That's a very good value. Strange that it still does not work. I am sorry.
As soon as I have some more time I will work further on the next revision of this board. There is an SD card controller in the pipeline and I have the schematics done for a version that supports DMA to make the A590 side car work. However, that release will be beginning of next year. This month is going to be too busy for any hobby work I'm afraid. (First up is Sint Nicolaas!)

[utri007]

Originally Posted by Mathesar

That's a very good value. Strange that it still does not work. I am sorry.
As soon as I have some more time I will work further on the next revision of this board. There is an SD card controller in the pipeline and I have the schematics done for a version that supports DMA to make the A590 side car work. However, that release will be beginning of next year. This month is going to be too busy for any hobby work I'm afraid. (First up is Sint Nicolaas!)

No need to be sorry, this is hobby and happy to be part of it. Some times this kind of things happen.

[Mathesar]

Oke, for a super simple SPI controller using old-school 7400 logic we will have to do the bit-shifting in software. The hardware will be a just a 1-bit interface
So, the trick is in the software. What is the quickest way of shifting 8 bits into memory? What do you think of this routine (the 1-bit interface is connected to bit#7 of the IO port):

;read one sector of 512 bytes to memory pointed to by (A2)
Read_Sector:	
		lea		SPI,a1		;pointer to SPI interface I/O port
		move.w		#511,d2		;init sector byte counter
		
Loop:		move.b 		(a1),d1		;read one bit
		add.w		d1,d1		;shift left
		move.b 		(a1),d1		;read one bit
		add.w		d1,d1		;shift left
		move.b 		(a1),d1		;read one bit
		add.w		d1,d1		;shift left
		move.b 		(a1),d1		;read one bit
		add.w		d1,d1		;shift left
		move.b 		(a1),d1		;read one bit
		add.w		d1,d1		;shift left
		move.b 		(a1),d1		;read one bit
		add.w		d1,d1		;shift left
		move.b 		(a1),d1		;read one bit
		add.w		d1,d1		;shift left
		move.b 		(a1),d1		;read one bit
		lsr.w		#7,d1		;shift right to right align complete byte
		
		move.b 		d1,(a2)+	;store byte
		dbra		d2,Loop	
		rts

According to my calculations this routine needs 130 cycles per byte. So, @7Mhz running out of chipmem we can do about 45 Kbytes/s or so....
Using a 14MHz CPU running out of fast ram we can do 107 Kbytes/s. Not too bad imho.

[PeteAU]

Originally Posted by Mathesar

According to my calculations this routine needs 130 cycles per byte. So, @7Mhz running out of chipmem we can do about 45 Kbytes/s or so....
Using a 14MHz CPU running out of fast ram we can do 107 Kbytes/s. Not too bad imho.

With no seek times, it should boot up WB pretty well
I'm sure a 68K ASM wiz will come along and shave a couple of cycles off.
Where in memory will SPI live?

[hooverphonique]

Originally Posted by Mathesar

Oke, for a super simple SPI controller using old-school 7400 logic we will have to do the bit-shifting in software. The hardware will be a just a 1-bit interface
So, the trick is in the software. What is the quickest way of shifting 8 bits into memory? What do you think of this routine (the 1-bit interface is connected to bit#7 of the IO port):

That doesn't look too bad regarding combining 8 bits to a byte - I have a feeling there's a solution where you can avoid the final right shift though, given the input goes into the sign bit.


How do you synchronize the spi read with the clock - is the hw generating a clock pulse each time the spi address is accessed?


I suppose this interface only supports a single spi mode then

[Mathesar]

Originally Posted by hooverphonique

How do you synchronize the spi read with the clock - is the hw generating a clock pulse each time the spi address is accessed?
I suppose this interface only supports a single spi mode then

Yes, I generate one clock pulse for each bit read or written using the data strobe signals. And multiple SD cards are easily supported by having multiple chip select lines. To latch the chip select line I am currently looking at the HCT74 and there are 2 flipflops in each package. So, 2 SD cards will be "free of charge" so to say. I think I can built the whole interface with 4 or 5 logic chips.

Edit: Oh, now I think you meant SPI modes as in clock polarity and such. Yes, only a single mode supported

[hooverphonique]

Originally Posted by Mathesar

Edit: Oh, now I think you meant SPI modes as in clock polarity and such. Yes, only a single mode supported

[pandy71]

74299?

[Mathesar]

Originally Posted by PeteAU

Where in memory will SPI live?

Somehere @$BFxxxxx or @$DAxxxxx without interfering with CIA' or A600/A1200 ide. There are plenty of addresses available there I think.

[Mathesar]

Originally Posted by pandy71

74299?

42?

[pandy71]

Originally Posted by Mathesar

42?

Great idea...

[Mathesar]

Originally Posted by pandy71

Great idea...

Now I get it . The number didn't ring a bell...
A hardware shifter would be quicker but would also require a lot more logic chips. It's not only the shifter itself, it's also a bit counter and some logic (interrupt, flag, waitstates, etc) to synchronize shifting with cpu access (the cpu needs to know when shifting is done so it can read the data). The whole idea is to keep the hardware as simple as possible so that anyone can build it.

[pandy71]

Originally Posted by Mathesar

Now I get it . The number didn't ring a bell...
A hardware shifter would be quicker but would also require a lot more logic chips. It's not only the shifter itself, it's also a bit counter and some logic (interrupt, flag, waitstates, etc) to synchronize shifting with cpu access (the cpu needs to know when shifting is done so it can read the data). The whole idea is to keep the hardware as simple as possible so that anyone can build it.

NP, from my perspective anything starting by 74 immediately trigger TTL.
Fair approach but probably everyone capable to order PCB (as probably nobody nowadays doing PCB by himself) and solder all elements and make board run is capable to solder even 3 more IC's.
Guys who prefer to buy assembled and working PCB probably don't care about 3$ more... And i have strong impression that 150KBps vs 500KBps is something worth such complication.
Anyway it was just quick idea.
Thank you for all work! Appreciate it very much.

[Mathesar]

Can anyone tell where the FAST ram in the A590 / GVP HD+ and all these other side cars ends up? I assume, as they are supporting autoconfig they will end up in Zorro II space. But the SCSI part will also be mapped there.

I ask because I need to map the ranger RAM to somewhere in Zorro II space the "dirty" way (so without autoconfig) to make it DMA capable. It is probably safest to map it high up in the Zorro II space. One candidate address is $900000 to $9FFFFF, I only need to swap a few wires for that. One will have to use the addmem utility though to use it...

Any ideas?