News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_doragasu

ROM board with a tiny DMA engine

Started by doragasu, 23:33, 14 January 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Bryce

I assume you don't own a logic analyser? If I find time I'll wire up a GA and give you a screenshot of what the reality looks like.

Bryce.

doragasu

Quote from: Bryce on 22:58, 26 January 17
I assume you don't own a logic analyser? If I find time I'll wire up a GA and give you a screenshot of what the reality looks like.

That would be very appreciated. I have a cheap 12 MHz Aliexpress one, but it is not fast enough to spot changes coming from rising and falling edges of a 16 MHz clock. If you could show in the same capture #PHI, #CAS, #RAS, READY, and #CPU, that could help a lot. #MREQ, #M1, #244EN
can be also interesting (and in fact any other control signal, but these are the ones I'm most intrigued about).

gerald

Quote from: doragasu on 22:29, 26 January 17

Almost everything makes sense... excepting the READY signal. If you look at the #RAS and #CAS signals, you can see that each microsecond three reads are made: two for the GA (#CPU = 1) and one for the CPU (#CPU = 0). The two GA reads are done using page read mode, as I suspected (#RAS is strobed once, and #CAS is strobed twice). The CPU read is done only if #MREQ = 0 (and it is not a refresh cycle), otherwise #CAS is not lowered. It makes perfect sense...

... BUT... READY signal is lowered when the CPU performs the read, and not when the GA does it!!! Everywhere I have read just the opposite, so maybe my interpretation of the signals is just wrong...
Indeed, there is a error in the state decoding.
- READY : U304 output should not be inverted (ie it's a NAND2 with one inverted input)
- CCLK : one inverter is missing on the output (ie U306 is a NOR2)

Note that the schematic is a work in progress  ;)

Bonus, a trace captured on a 464 + 40010
[attach=2]

doragasu

@gerald Thanks a lot! It looks I almost nailed it, other than the READY signal, my drawing looks the same as the capture :)

Quote from: gerald on 18:24, 27 January 17
- READY : U304 output should not be inverted (ie it's a NAND2 with one inverted input)

I suppose you mean it's an AND2 with one inverted input. I'll have to update my drawing. Thanks again for the info and for the RE work on the GA!

gerald

Quote from: doragasu on 20:32, 27 January 17I suppose you mean it's an AND2 with one inverted input. I'll have to update my drawing. Thanks again for the info and for the RE work on the GA!
Yes  :picard:

Bryce

I assume you don't need me to capture it now? :)

Bryce.

gerald

Quote from: Bryce on 10:38, 28 January 17
I assume you don't need me to capture it now? :)
If you're like me, nothing will prevent you to get your analyser out. But it may not be the best time with all the rust you should have on your bench  ;)
Actually, that a trace I captured when developing my RAM/ROM extension card.

Bryce

Tell me about it, I have never vacuumed this room as often as I have in the last 3 days! :D

Bryce.

doragasu

Quote from: Bryce on 10:38, 28 January 17
I assume you don't need me to capture it now? :)

Bryce.

I don't need it, but thank you very much anyway!

Working on the schematic right now...

doragasu

One more question: How much current can I safely draw from the expansion port 5V rail? I made a quick estimation, and I think my cart should not draw more than 50 mA: 19 mA the CPLD, 8 mA the transceivers, 22 mA the flash chip. Flash chip power draw is computed for 4e6 reads per second, and transceivers for inputs/outputs switching at 4 MHz (what will happen only for the clock line). So real power consumption should be much lower.

I don't think 50 mA can cause problems, but I'm asking just to be on the safe side...

Bryce

50mA is absolutely no problem to take from the expansion port. Other expansions pull a lot more (>200mA).

Bryce.

rpalmer

While bryce is correct that 50ma will not hurt, it must also be considered against what expansions are before/after yours as they too will draw from the CPC if they have no separate power supplied.

doragasu

As always, thanks for the quick responses!

Quote from: rpalmer on 12:50, 06 February 17
While bryce is correct that 50ma will not hurt, it must also be considered against what expansions are before/after yours as they too will draw from the CPC if they have no separate power supplied.

Of course, but I'm afraid that is out of my control ;)

Bryce

On Centronics versions of the CPC, the supply traces to the expansion port are seriously wide and can easily supply whatever your PSU can throw at it.
It's only on edge connector CPCs that I'd be worried. The last few millimeters of 5V positive trace go down 0.4mm width. Theoretically it could supply about 1.2A, however it will be getting hot at about 1A and would instantly burn through if any short circuit occured.

Bryce.

zhulien

i couldn't find much info on the net for these hd64b180rop (http://www.microbeetechnology.com.au/store/hd64b180rop-6mhz-enhanced-z80-microprocessor.html) but it says it has enhancements such as dma inbuilt.  I couldn't find whether they are pin compatible with z80 or not either.

Bryce

Quote from: zhulien on 00:08, 11 February 17
i couldn't find much info on the net for these hd64b180rop (http://www.microbeetechnology.com.au/store/hd64b180rop-6mhz-enhanced-z80-microprocessor.html) but it says it has enhancements such as dma inbuilt.  I couldn't find whether they are pin compatible with z80 or not either.

Eh.... No. It has 64pins and a Z80 has 40pins, so it's definitely not pin compatible.

Bryce.

zhulien

hehe, yes, i missed that 64pins note. silly me.

doragasu

A render while I wait for the PCBs to arrive...



And now a question:

Currently I have to map on the I/O range 10 registers, the one for the ROM selection, and other 9 for the DMA engine. The ROM select register is at 0xDFXX, but where should I map all the other nine? For the current tests I'm using bits A7 ~ A15, so they are mapped at 0xD80X, 0xD88X, 0xD90X, 0xD98X, etc... but I'm not sure this is a good place to map them. As always, suggestions are welcome.

Bryce

A fine looking piece of kit. What's the third row of holes above the header for?

Regarding the address assignments, I'd take a look at the table here: http://www.cpcwiki.eu/index.php/I/O_Port_Summary and choose some area that doesn't clash with other popular hardware or choose an address that's already used for something that shouldn't or wouldn't be used with your device at the same time.

Bryce.

arnoldemu

Quote from: doragasu on 07:56, 14 February 17
A render while I wait for the PCBs to arrive...



And now a question:

Currently I have to map on the I/O range 10 registers, the one for the ROM selection, and other 9 for the DMA engine. The ROM select register is at 0xDFXX, but where should I map all the other nine? For the current tests I'm using bits A7 ~ A15, so they are mapped at 0xD80X, 0xD88X, 0xD90X, 0xD98X, etc... but I'm not sure this is a good place to map them. As always, suggestions are welcome.

The CPC I/O ports are partially decoded.

So your choice of D8xx and D9xx may not be good:

Hardware deviceRead/WritePort bits
b15b14b13b12b11b10b9b8b7b6b5b4b3b2b1b0
Gate-ArrayWrite Only01--------------
RAM ConfigurationWrite Only0---------------
CRTCRead/Write-0----r1r0--------
ROM selectWrite only--0-------------
Printer portWrite only---0------------
8255 PPIRead/Write----0-r1r0--------
Expansion PeripheralsRead/Write-----0----------
Ideally choose a range within Expansion Peripherals and one that is not yet taken.

Your rom select port is fine you can freely use that.


My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

doragasu

Quote from: Bryce on 09:28, 14 February 17
A fine looking piece of kit. What's the third row of holes above the header for?

Third row is connected pin by pin to the second one. It's to be able to solder to the PCB a card edge connector instead of a DIL pin header, in case you prefer connecting the cart directly to the CPC instead of using an MX4. (BTW the render has a flaw, the MX4 connector must be soldered on the other side of the PCB, but I'm too lazy to change it).

Thanks all for the info on the port mappings.

Bryce

Quote from: doragasu on 07:56, 15 February 17
Third row is connected pin by pin to the second one. It's to be able to solder to the PCB a card edge connector instead of a DIL pin header, in case you prefer connecting the cart directly to the CPC instead of using an MX4. (BTW the render has a flaw, the MX4 connector must be soldered on the other side of the PCB, but I'm too lazy to change it).

Thanks all for the info on the port mappings.

Nice solution.

Bryce.

doragasu

I have been working on the DMA. Now I synchronize writes with the READY signal. In the following simulation:

       
  • DMA is started writing to $DB00 (will remap these registers later).
  • Controller requests DMA (lowers #BUSRQ)
  • Controller waits until bus is granted (#BUSAK is lowered).
  • Controller waits to the first SYNC pulse (to synchronize following transfers).
  • One byte is read from Flash src address in 1 cycle
  • Readed byte and dst address are put on the buses, #MREQ and #WR signals are lowered to write to RAM.
  • Controller waits until the READY pulse occurs, to make sure the byte is written to CPC internal RAM. Then address and data are tristated, #MREQ and #WR are raised. Addresses are increased (if requested).
  • Steps 5 to 7 are repeated until transfer is completed.
Byte read/write (steps 5 to 7) take 1us (4 clock cycles). If my current understanding of the CPC internals is correct, this should work.




I have synthesized the design, and it fits in a 2€ CPLD  :) (currently using 104/128 macrocells).


Bonus: I have implemented another DMA mode, anyone dares guessing what is it for?  :P



arnoldemu

I believed it would be possible. Thank you for making it true :)

Is the new dma mode a blitter with masking like on Amiga?

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

doragasu

Well, I don't still know if it's possible. It should, according to my understanding of the CPC. But I cannot be sure until I test this on the real machine (captures above are simulations, with stimulus generated by me).

The first DMA mode works with the CPU stopped. Although the "bonus" DMA mode works in parallel with the CPU, I'm afraid it is not a blitter. I do not know how the Amiga blitter works, but I suppose it works in parallel with the CPU, accessing memory while the CPU does not need it. I don't think that can be done with the CPC because I suppose the RAM chips are almost always busy. It looks like the GA is always reading from RAM, even when screen is not being drawn (during CRT vertical blanking for instance).

What could maybe be done is a mode running in parallel with the CPU and stealing cycles from it. E.g. it could run in parallel with CPU, and let the CPU access RAM once each 2 microseconds (instead of once each microsecond). But I don't think this could be very useful...

Powered by SMFPacks Menu Editor Mod