News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

ACU ROMboard remix not working! Help required.

Started by The Equalizor, 11:34, 15 October 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

The Equalizor

Hi Everyone,


I've been remixing the ACU Romboard and I'm having a few issues, weirdly enough only with the thing working alongside Cartridges.


The board works perfectly, the ROMs are visible and work without error.


However when I put in *some* carts (Klax being the main offender) the game just crashes instead of starting. Even on my C4CPC cartridge the game Klax just crashes. None of the GX4000 converted games on the C4CPC cartridge load at all, they just mostly initialise the ROMs before startup, and then the game never starts. Even Burnin' Rubber just resets instead of actually starting.


I have attached PDFs of the schematic I drew (which the PCBs were directly produced from) and also the relevant pages in the Article from the original designer. Please note I have changed this from a 6 to 4 Romboard so the circuit isn't completely identical, but I'm certain someone who's a bit of an expert will spot the issue straight away.


If it makes a difference I'm using HC logic instead of LS but from what I've read, in this application that shouldn't matter.


Any help would be greatly appreciated.


Cheers


Rob

arnoldemu

Hi Rob,

Is the rom number partially decoded by the romboard?

External roms override the cart roms if selected so if they are partially decoded they could be enabled in preference to the cart pages.

EDIT: I think so, it decodes D4-D0. It needs to decode D7-D0 and ensure they're 0.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

The Equalizor

Thank you for your reply :)


I am literally following the "schematics" in the article for the acu romboard and i think it mentions that d3 should always be low and that it decodes d0 to d2. Its a very old article without an actual full schematic but yeah I'm not an expert, i just wanted a small romboard to fit inside my custom plus. The way its looking i'm suspecting that the hardware design isn't fully plus compatible and i've wasted a weeks worth of schematic design and a bit of money.


I did have 5 megaflash PCBs done at the same time but I'd love to get this board working as its super simple and compact.


Any further help you can provide would be greatfully received.


Regards


Rob

IanS

You should tie the unused inputs of U3 to something, you can link 11 and 12 to another used input (like you did with pins 1,2 and 3)

Pin 11 of U1D should not be connected to ground. It's good that you tied the inputs to a known level (GND), but unused outputs should be left unconnected.

As has been mentioned, it is only decoding the lower 4 bits of the data bus, so each rom will appear in every 16th position. So Rom 1, will also appear as Rom 17 (and 33, 49 etc.). If the cartridges appear as higher rom numbers , then the two will clash. (Cartridges appear to use roms 128-159 http://www.cpcwiki.eu/index.php/Arnold_V_Specs_Revised)

So you'll need to find a way to only enable your roms if D4-D7 are set to zero.

The Equalizor

Thank you for your insight guys, in a way I'm happy that it wasn't me being a total div that stopped this thing from working correctly.


Ian, or anyone else :-) can we discuss further about the logic required to ensure that when D4-D7 are zero the ROMs are enabled and if not they are disabled.


I'm not an expert (as I've admitted before) but I usually muddle through. This is Phil Cravens design from ACU, and I'm not knowledgable enough to do this mod on my own so I'd appreciate any suggestions as to which logic chip I should use and where on this board would be a suitable place to connect it.


Regards


Rob



IanS

I'm not convinced the design this is based on was any good when it was first designed. It only latches the rom number when D3 is low, so on an 664/6128 it wouldn't play well with another romboard that was providing roms 8-15. It seems to rely on ROM 0 (Basic) probably being selected before any other rom is selected as the decoded outputs of the HC137 are always enabled when A14 is high, regardless of rom selected.

You may be able to add some extra decoding to only latch the rom number when D3-D7 are low. Something like a 74HC138 may do the job, connect D3-D7 to A0-A3,E1 and E2. Connect E3 to +5v. Then feed Y0 into Pin 10 of U1C instead of D3.  Y0 will only be low when all of D3-D7 are low. Outputs Y1-Y7 awould be unused.

Can anyone else check my idea, does it sound like it would work.

The Equalizor

Ian,


No need to ask anyone else if it works - it does! Deadbugged a 138 onto my board and wired it up. Everything that didn't work before now works! Thank you so much!


I'll alter the schematic and get new boards made.


I'd like to buy you a drink - please send me your Paypal details or something like that and I'll gift you an appropriate amount.


Thank you once again!


Rob


IanS

That is good news.  No need for paypal, happy to help.

It's still not a great design, I'm just not sure what else to suggest without changing the whole circuit.

The Equalizor

Thank you Ian,


Yeah its not a great design but its only a little pocket romboard and as a plus it now actually works!


Regards


Rob

IanS

Instead of a 74hc138, you could use another 74hc32, wired up as effectively a 5 input OR gate. May be easier as you are already using 74hc32's in your BOM.


The Equalizor

Weirdly enough I was looking into that as a possibility as it struck me when I was looking through the schematic. But I have loads of 138's that I bought for the Plus to PS/2 keyboard interface that I remixed from the Gerald version of the CPC to PS/2 interface so I'm happy just to use them.


Cheers


Rob

Bryce

#11
Quote from: IanS on 23:54, 16 October 17
Instead of a 74hc138, you could use another 74hc32, wired up as effectively a 5 input OR gate. May be easier as you are already using 74hc32's in your BOM.

How exactly would you do that? The 138 is a latch and holds the value, the 32 doesn't retain it's output after the input has changed.

Bryce.

Edit: Ignore that. I just read your earlier post and see you weren't suggesting replacing the original 138 with a 32.

IanS

Quote from: Bryce on 14:42, 17 October 17
How exactly would you do that? The 138 is a latch and holds the value, the 32 doesn't retain it's output after the input has changed.

Bryce.

Edit: Ignore that. I just read your earlier post and see you weren't suggesting replacing the original 138 with a 32.
The original "138" is actually a 137, the 138 doesn't latch.

Bryce


Powered by SMFPacks Menu Editor Mod