Hi all (LowerROM Board owners mainly),
As I mentioned before, on a standard 6128, ROM 7 isn't connected to the /ROMDIS signal, so connecting the LowerROM Board will just disable ROM 0. On the cost down (pre-ASIC) 6128 and CPC+ models, the wiring is different and the LowerROM Board disables all internal ROMs including number 7. This of course results in the disk commands no longer being available (unless you have an external ROM 7 behind the LowerROM Board).
Now TotO has informed me that he has a version 2 6128, ie: not a pre-ASIC board, but the 6128 board that used the SED9420 data separator, and it also disables ROM 7 when the LowerROM Board is connected. This means two things:
1 - Only version 1 6128s can't disable ROM 7 externally using /ROMDIS.
2 - If your 6128 is a version 2, then you can replace AMSDOS using the MegaFlash without making any internal changes.
Has anyone else got a LowerROM Board and a Version 2 6128 to confirm that this is the case on all version 2 boards?
TotOs board is a type MC0020C.
Bryce.
I did test 2 6128 with my flash board, which can replace FW/BASIC rom as well as ROM7.
I've permanently forced ROMDIS high using a wire to 5V, and started the CPC with and without enabling external ROM7
Without the external ROM7, CPC boots OK on external FW/BASIC, but AMSDOS (internal ROM7) is still there.
With the external ROM7, CPC boots OK on FW, initialise other high ROM until it get on AMSDOS and crash.
CPC board version are MC00020B and MC0020G
Is Toto's ROM 7 really disabled by the ROMDIS signal ? ie does he get the "press play than any key" message when using any load/run/cat commands using only the lower board rom ?
Yes, that's what he says. When the LowerROM board is connected, it says unknown command to all the disk related RSX commands according to him. As soon as he disables the LowerROM Board the RSX commands are back. His other 6128 doesn't do this. ROM 7 is still available as expected when the LowerROM Board is connected.
Bryce.
Quote from: gerald on 16:01, 28 January 13Is Toto's ROM 7 really disabled by the ROMDIS signal ? ie does he get the "press play than any key" message when using any load/run/cat commands using only the lower board rom ?
I have plugged the LowerROM board alone.
All RSX commands related to the AMSDOS return "Unknown Command", and CAT return "Ready" w/o doing things... When I disabble the board (or remove it), all work fine again.
It's why I think that ROM7 is disabled.
But, that not explain why the "G" revision of the board (released after B I though) not do the same.
That's strange.
I checked on the MC00020G that the ROM7 OEn and CS are compliant with the schematics. So this should not work ;D
Quote from: TotO on 17:03, 28 January 13
All RSX commands related to the AMSDOS return "Unknown Command", and CAT return "Ready" w/o doing things...
Without ROM7, the CAT/LOAD/RUN command would use the tape. So you should have a "Press play than any key" message.
I am more thinking your CPC has a flaw.
I would check the following :
- If you have a 2nd LowerRom board, confirm the behaviour is the same, on both CPC
- Try re-settling the Z80 and CRTC on they socket. You may have some weak contact on A15/ROMEn that are both used by the internal ROM and the LowerROM.
- Try a spare Z80 (or swap with the other CPC). My 464 decided one day that it would not accept anymore my SSA1/DDI1/DART scanner, but was OK with the DDI only. Changing the Z80 fixed the problem.
By the way, it seems we do not have a schematic of the disk part for these version 2 6128 (with SED9420).
In the 6128 service manual, schematic is associated with PCB MC0009A.
The one in the amendment Service manual is associated with a MC00057A, but there is no disk interface.
By checking the OEn/CSn on the board, I've found that the gate allocation is different on MC00020G compared to MC00009A schematic.
Quote from: Bryce on 11:02, 28 January 13
::: If your 6128 is a version 2, then you can replace AMSDOS using the MegaFlash without making any internal changes.
This is what I'm telling you since years, and you did never ever believe me. See, TFM is always right ;) ... but not without TotO to support him :laugh:
Quote from: gerald on 17:25, 28 January 13
Without ROM7, the CAT/LOAD/RUN command would use the tape. So you should have a "Press play than any key" message.
No, because I use the FW3.1 into the LowerROM.
Which means that the Tape support was removed... All commands return Ready, except RUN" or LOAD"
(with the double-quote) that should return "File already open". And it's the case.
That's ok, but it still doesn't explain why your board is disabling ROM 7. I have a feeling that the last owner has modded something that's not obvious to see.
Bryce.
Quote from: TotO on 21:28, 28 January 13
No, because I use the FW3.1 into the LowerROM.
That mean the tape support was removed... All Tape commands return Ready, except RUN" or LOAD" (with the double quote) that return "File already open". And it's the case.
Ok for the run/load command behaviour, but the unknown command may be just the result of the ROM not being registered, and not by being physically disabled by ROMDIS.
If you CPC has a problem, the rom7 may not be seen as a valid sideway rom (ie ROM byte 0 equal to 0,1 or 2), so not RSX are registered.
I have opened the case and seen nothing (cut or gate) everywhere on the top and where you usually does the ROM7 hack.
And on the back too...
Here the pictures, because not stored on CPCWiki for this model:
http://totoonthemoon.free.fr/images/cpc/PART1.JPG (http://totoonthemoon.free.fr/images/cpc/PART1.JPG)
http://totoonthemoon.free.fr/images/cpc/PART2.JPG (http://totoonthemoon.free.fr/images/cpc/PART2.JPG)
http://totoonthemoon.free.fr/images/cpc/PART3.JPG (http://totoonthemoon.free.fr/images/cpc/PART3.JPG)
But, sure, I will check again to know why.
Quote from: gerald on 21:55, 28 January 13
Ok for the run/load command behaviour, but the unknown command may be just the result of the ROM not being registered, and not by being physically disabled by ROMDIS.
If you CPC has a problem, the rom7 may not be seen as a valid sideway rom (ie ROM byte 0 equal to 0,1 or 2), so not RSX are registered.
But, if my ROM got a problem... It must be always? Not only using the LowerBoard, no?
No, the electronics on the LowerROM board could be effecting a weak bit on the Data or Address bus and unintentionally blocking the ROM 7 from being initialised. Try connecting the MegaFlash to it and see what happens when the external ROM 0 or 7 is enabled / disabled.
Bryce.
Quote from: TotO on 22:01, 28 January 13
But, if my ROM got a problem... It must be always? Not only using the LowerBoard, no?
Your ROM behaviour is the visible symptom.
Bryce : how you make sure the LowerROM EEPROM is not driving the data bus when ROM7 is selected ?
I understand that the ROMDIS from expansion connected to the LowerRom board (MegaFlash/Rom) is taken into account so external ROM can disable the LowerROM, but I do not see a way to prevent the internal ROM7 to drive the data bus without doing HW modification on the main board.
There's nothing to stop it from driving the bus at the same time as the ROM 7. It's a timing glitch in the CPC that allows it to work, but obviously not on all CPCs. Unfortunately I don't have the schematics for the PCB version, so I can't check if something is different. I've checked the two 6128s I own (both version 1) and both retain ROM 7 functionality with the LowerROM Board connected.
Bryce.
Quote from: Bryce on 23:11, 28 January 13
There's nothing to stop it from driving the bus at the same time as the ROM 7. It's a timing glitch in the CPC that allows it to work,
That's called a bus contention. A glitch is a transient state. Here you have two devices that drive the data bus at the same time for about 1us.
Quote from: Bryce on 23:11, 28 January 13
but obviously not on all CPCs..
The contention will apear on all CPC (exept the + and pre-asic one), but the variation in internal/external device drive capability will make the ROM visible to the Z80 or not.
Quote from: Bryce on 23:11, 28 January 13I've checked the two 6128s I own (both version 1) and both retain ROM 7 functionality with the LowerROM Board connected.
That mean that your internal ROM has stronger drive than the external one so the contention is won by the internal ROM and the amsdos is registered.
On Toto's CPC, the internal ROM is weaker, so it is not registered. TFM CPC looks like it also had weak internal ROM.
The only advice I would have is :
- either disable the internal ROM7 by removing it physically or patching the board to allow proper control of OEn/CEn.
- or use an external Flash/Rom board the the AMSDOS rom in slot 7 (slot 7 being active) so the external Flash/Rom board will drive the ROMDIS when ROM7 is accessed. This will disable the LowerROM EEPROM while both ROM 7 (internal AND external) will drive the SAME data. Using a alternate ROM like PARADOS will bring contention back.
Yes, I'm well aware of what's happening. I didn't want to use the word bus contention because many people here won't know what that means. Glitch (like bug) can mean almost anything, including a transient state.
The version 2 6128s have a slightly different schematic (SED9420 separator), which I thought might be responsible for the varying results.
TFMs CPC is a Pre-ASIC version I think.
As far as the design of the LowerROM Board is concerned. It's not my design, I just did the layout and produced a few of them. The original design was from ACU as far as I can remember. The only other change I made was to allow two ROMs to be stored on the EPROM (the original design only had one image) and the reset button. If I were to design my own LowerROM board I would have done it completely different with proper decoding, but it also would have been a bit more expensive. At the time I built them, people were looking for a very low-cost Lower ROM replacement and as usual, low-cost usually means you have to cut corners somewhere. It's still a very good solution to play 464 only games on a 6128 and to get BASIC 1.1 on a 464.
In my original posting about the LowerROM, I mentioned that it disabled ROM 7 (as I expected it to), but I later found that my 6128 wasn't disabling ROM 7 when I connected it.
Bryce.
I think we should use bus contention wording and describe what it means (a shortcut) so people are aware of what is really happening.
Once they are properly informed, that can take they own decision.
They also have to understand that the LowerROM board may or may not inhibit the AMSDOS ROM, but at the expense of an increased power consumption and a potential break of either EPROM or AMSDOS ROM.
We should not leave the feeling that there are CPC that works and CPC that doesn't.
There is no magic, the only way to safely disable the AMSDOS ROM is patch the motherboard.
Now I think that the LowerRom has a real use but we should think of a proper way to disable all internal ROMs via the ROMDIS signal.
Well as you mention yourself: There is no way of disabling ROM 7 on the original 6128s without modifying something inside the CPC and that's something most people aren't likely to do themselves. As I'm not up to speed on the CPC firmware, maybe this could be done in code? No idea, maybe some of the coders here could make suggestions.
There's not really a realistic chance of the LowerROM board damaging the internal ROMs, or what do you mean by: "a potential break of either EPROM or AMSDOS ROM."?
As far as jargon is concerned, I often get told that I use words that no-one else would understand, so I tend to over-compensate sometimes and use generic words that aren't 100% accurate, but explain the situation. If this was purely an electronics forum I would probably use different terminology, but on a retro forum you can't really assume that everyone will understand (and I'm too lazy to explain all the details sometimes :D )
Bryce.
Quote from: Bryce on 13:07, 29 January 13
There's not really a realistic chance of the LowerROM board damaging the internal ROMs
The shortcut can do it, but yes, the probability is quite low as the contention will happen at most 1/4 of the time (thanks to CRTC stealing cycles) and only when accessing the ROM itself and if bits are different.
But you surely want to avoid the "Bryce broke my ROM!!!" kind of message ;D
Quote from: Bryce on 13:07, 29 January 13
As far as jargon is concerned, I often get told that I use words that no-one else would understand, so I tend to over-compensate sometimes and use generic words that aren't 100% accurate, but explain the situation. If this was purely an electronics forum I would probably use different terminology, but on a retro forum you can't really assume that everyone will understand (and I'm too lazy to explain all the details sometimes (http://www.cpcwiki.eu/forum/Smileys/SoLoSMiLeYS1/cheesy.gif) )
I think we should use the proper wording whenever we can, and fall back to generic word when there is no other way. Too much generic wording may cause confusion as well. So I will not explain the electromigration risk of the LowerRom :laugh:
Quote from: Bryce on 13:07, 29 January 13
maybe this could be done in code
No way, this is harware :( .
Ok, update, just to confuse the hell out of everyone (including myself).
As I am at home today and have the luxury of time to mess about with CPCs :) I decided to test it all again. Here's what I've just discovered:
The final version LowerROM Board ALWAYS disables ROM 7 on all of my 6128s - ie: it doesn't initialise ROM 7. So no bus contention is possible unless (as Gerald mentioned) you connected an external ROM 7 that had a different OS other than AMSDOS. In this case the internal EPROM would be enabled and answer in parallel to the external ROM 7. Not a problem if they have the same contents, but would cause contention issues if the OS was different.
The confusing bit comes from the fact that I have been using my prototype LowerROM at home, not a final version. And for some reason (although the schematic is identical) this board is letting ROM 7 initialise. This may be due to dodgy soldering or the fact that it's built on a vero board, but eitherway it's not reacting like the final version.
Now this brings me to the next question - aimed at TotO: Your MC0020C board disables (doesn't initialise) ROM 7, this is how it should be. But you said your other CPC did initialise ROM 7 and it even allowed you to use RSX commands, so what caused that to happen on a final version LowerROM Board and what version Mainboard is it? Can you check this again and confirm it is really doing this?
Bryce.
Edit: Regarding the "could this be done in code", I was more thinking of changing the firmware to ignore ROM 7 completely and re-direct ROM 7 references to actually look at ROM 31 for example? This would look like the ROM 7 still existed and the internal one would never get initialised? Would that be possible? (as I mentioned, I haven't a clue about Firmware).
Here my personal message:
Quote
Hello Bryce,
I have plugged the LowerROM board on my second 6128 (AZERTY) and the ROM7 look to be disabled.
All RSX commands related to the AMSDOS return "Unknown Command", and CAT return "Ready" w/o doing things...
I got a MC0020C mainboard with a MC6845P CRTC (Type 2, as displayed on the screen)
If I disable the LowerBoard, all work fine.
Strange ???
I don't said that all work on my first CPC, but that not work on my second.
I don't notice that on the first, but I may check again this sunday.
QuoteRegarding the "could this be done in code", I was more thinking of changing the firmware to ignore ROM 7 completely and re-direct ROM 7 references to actually look at ROM 31 for example? This would look like the ROM 7 still existed and the internal one would never get initialised? Would that be possible? (as I mentioned, I haven't a clue about Firmware).
Need to see what can be done.
Ah, ok. I assumed by the "It doesn't work on my second CPC" meant that it did work on your first CPC. In that case all is ok and working as it should be. I think you'll find that your other CPC also losses it's RSX commands when the LowerROM is connected.
Update on my Prototype LowerROM - I replaced the badly oxidised connector on the prototype board and ROM 7 is no longer initialising. Before I did that, I also tested whether it was happening 100% of the time. It was actually hit and miss. Sometimes ROM 7 was there, sometimes it wasn't. Either way, a clean connection resolved the issue.
Bryce.
Sorry to be confuse.
I said "my second" (used the week), because I have not noticed that on the first (used the week-end)
In all cases, that show a problem that nobody has reported since... It's why I though that I get ROM7 disabled.
Quote from: Bryce on 15:37, 29 January 13
Update on my Prototype LowerROM - I replaced the badly oxidised connector on the prototype board and ROM 7 is no longer initialising. Before I did that, I also tested whether it was happening 100% of the time. It was actually hit and miss. Sometimes ROM 7 was there, sometimes it wasn't. Either way, a clean connection resolved the issue.
Could that be used to introduce a switch? So ROM7 could be switched on and off.
Quote from: Bryce on 13:07, 29 January 13
... As I'm not up to speed on the CPC firmware, maybe this could be done in code? No idea, maybe some of the coders here could make suggestions.
That's not an well option, since a lot of programs (games, apps. ect..) initialize ROM 7 as DOS ROM. If the DOS would be underneath another ROM number, the program would crash.
Do these programs do it directly or use Firmware calls to initialise the ROM. If they use the Firmware, then you could re-direct the calls to ROM 7 to the new ROM number?
The LowerROM isn't really disabling ROM 7, it's only inhibiting the initialisation. So if an external ROM 7 is initialised, then the internal ROM 7 will be answering the requests to the external ROM 7 in parallel. So the external ROM 7 still couldn't be an alternative version, it would have to be an exact copy of AMSDOS.
Bryce.
Forget it, most games bank in ROM7 and use routines of ROM7. Some may use the firmware, but most do it directly.
Why don't you try it by yourself? Move AMSDOS from ROM 7 to ROM 5 (for example) and see how much game are still running. No, don't take all that cracked games, take original stuff. ;) And for Apps. check OCP art studio. ;)
If I have understood right, to be able to patch ROM7 with MEGAflash is necessary to set pin 20 or pin 22 of internal AMSDOS ROM to 5v. Isn't it?
There are not another way?
Quote from: wilco2009 on 19:29, 21 October 13
If I have understood right, to be able to patch ROM7 with MEGAflash is necessary to set pin 20 or pin 22 of internal AMSDOS ROM to 5v. Isn't it?
There are not another way?
Pin 20 or 22 to 5V is not a good idea. Connecting anything directly to 5V is generally not recommended (especially if you aren't sure).
Linking pin 13 (or any of the connected tracks ) of IC210 to GND will stop the internal rom from ever being selected.
As IanS says, don't directly connect either of these pins to 5V. The best way to do it is to add a switch that disconnects pin20 from the pcb and instead connects it to 5V via a 10K resistor. This will allow you to enable/disable ROM7 when you wish. See attachment.
Bryce.
Quote from: IanS on 20:08, 21 October 13
Pin 20 or 22 to 5V is not a good idea. Connecting anything directly to 5V is generally not recommended (especially if you aren't sure).
Linking pin 13 (or any of the connected tracks ) of IC210 to GND will stop the internal rom from ever being selected.
[/size]Quote from: Bryce on 09:18, 22 October 13As IanS says, don't directly connect either of these pins to 5V. The best way to do it is to add a switch that disconnects pin20 from the pcb and instead connects it to 5V via a 10K resistor. This will allow you to enable/disable ROM7 when you wish. See attachment.
Bryce.
[/size]
Thanks to both.
I'll try with the selector option.
Quote from: Bryce on 09:18, 22 October 13
As IanS says, don't directly connect either of these pins to 5V. The best way to do it is to add a switch that disconnects pin20 from the pcb and instead connects it to 5V via a 10K resistor. This will allow you to enable/disable ROM7 when you wish. See attachment.
[/size][size=78%]
Why do you suggest cutting a pin when you can just attach two wires.
Linking pin 13 (or any of the connected tracks ) of IC210 to GND (via a switch) will stop the internal rom from ever being selected. No permanent damage required.[/size]
Just because I prefer to do things they way I was taught. Your solution would have been considered bad practice at least the way we learnt it back then. That's not saying your solution doesn't work or isn't good. It's just not the way we were taught it back then.
Pulling pin 13 low means you are holding all the ouputs of the 74LS136 low. I know they are open collector, so it won't damage them or anything, but you are also permanently dropping 5V across R211. Ok, it's only going to pull 5mA[nb]In the type of commercial electronics I usually design, you'd be fired for knowingly "wasting" 5mA[/nb] or so, but it's not good practice. Of course cutting a pin isn't exactly good practice either, but from a schematic point of view I prefer to do it this way.
To use your way and make it more "Fussy bastard Bryce compatible" :D , I'd suggest removing R211 as well as adding your link.
Bryce.
Edit: Here's a suggestion that uses your pin 13 solution, doesn't involve cutting any pins, makes it switchable and removes the 5mA loss across R211.
Thanks again, I try this last solution. ;)
Easy and clear.
Quote from: Bryce on 13:39, 22 October 13
To use your way and make it more "Fussy bastard Bryce compatible" :D , I'd suggest removing R211 as well as adding your link.
Edit: Here's a suggestion that uses your pin 13 solution, doesn't involve cutting any pins, makes it switchable and removes the 5mA loss across R211.
The 5ma is being "wasted" whenever Rom 7 isn't enabled now, so I don't think it's a big deal. My method has the advantage that you only require 2 wires for the switch.
Yeah, but I'm an over pedantic perfectionist. And my day job involves "worrying" about lost µAs, so to me it seems like a lot. All three versions are good solutions and work fine, it's up to the modder to decide which solution he/she prefers.
Bryce.
According to Flynn perfection can't be reached... but we can reach out for it! And I like that ;)
Who's Flynn?
Bryce.
No, Tron Legacy...
so just 'junior' nerd :o
Ah, ok. I thought you meant this one: Flynn - CPCWiki (http://www.cpcwiki.eu/index.php/Flynn) :D
Bryce.
... an obvious reason for choosing a pseudo :laugh:
Ouch!, my 6128 not match with the schematics.
Pin 13 of IC210 is not connected with R211 in any side, and seems to be not used.
I think the best way in my case is to use the first solution proposed by Bryce. The function of pin 20 in a ROM is known and sure. ;)
To add more confusion (or clarity?) to this topic - I have two 6128s here, one of them (an MC0020C) gets the ROM 7 disabled when you connect the LowerROM, the other (an MC0020I) does not.
There seem to be advantages & disadvantages to both - with ROM 7 disabled, you can add an external ROM7 of your choosing, but if you don't then you have a basically have an unusable CPC. Without it disabled, you can use the CPC without a ROM board, but you can't replace ROM 7 without hacking the CPC.
Quote from: Munchausen on 14:32, 24 October 13
To add more confusion (or clarity?) to this topic - I have two 6128s here, one of them (an MC0020C) gets the ROM 7 disabled when you connect the LowerROM, the other (an MC0020I) does not.
Haha, I discussed this with Bryce about 28345697 times - and finally You prove that external expansions can disable the internal ROM 7 !!! Thank's!!! That clearly explains a lot. :)
Quote from: wilco2009 on 13:33, 24 October 13
[size=78%]Ouch!, my 6128 not match with the schematics.[/size]
[/size]
[/size][size=78%]Which version does it match? - [/size][/size][size=78%]http://www.cpcwiki.eu/index.php/Mainboard_Versions[/size]
Quote from: TFM on 15:22, 24 October 13
[size=78%]Haha, I discussed this with Bryce about 28345697 times - and finally You prove that external expansions can disable the internal ROM 7 !!! Thank's!!! That clearly explains a lot. [/size] :)
Yes you can disable the internal DOS rom via the expansion connector on some editions of the 6128, but not all.
Exactly! That's what I've been trying to tell TFM for a long time.
Bryce.
Quote from: TFM on 15:22, 24 October 13
Haha, I discussed this with Bryce about 28345697 times - and finally You prove that external expansions can disable the internal ROM 7 !!! Thank's!!! That clearly explains a lot. :)
Well, he 'proved' that external expansions can disable the internal rom 7 on SOME 6128. And discussing that 28345698 or more will not make this work on ALL 6128 :P .
Talking about proof, it would be nice to :
1. identify revision of board that can disable ROM 7 from external extension.
2. Get an updated schematic for these revision.
Quote from: wilco2009 on 13:33, 24 October 13
Ouch!, my 6128 not match with the schematics.
Pin 13 of IC210 is not connected with R211 in any side, and seems to be not used.
I think the best way in my case is to use the first solution proposed by Bryce. The function of pin 20 in a ROM is known and sure. ;)
Schematic in the service manual is for board revision MC0009A (and should be valid for MC0009 in general).
In the Amendmend service manual, while the floppy section schematic is not available, from the PCB (MC0023A revision) you can see that the gate that drives pin 13 is not used at all, but also that R211 is now connected to pin 10 of IC210. A quick look seems to indicate that they changed the gate assignment when changing the floppy data separator (ie, there is one 74LS132 gate free now).
So the modification should apply, but on pin 10 of IC210 instead of pin 13.
Quote from: Bryce on 20:07, 24 October 13
Exactly! That's what I've been trying to tell TFM for a long time.
Bryce.
Haha! Oh no! You always refused that possibility completely. But never mind, I can life with that - as good winner ;)
Quote from: gerald on 20:33, 24 October 13
Well, he 'proved' that external expansions can disable the internal rom 7 on SOME 6128. And discussing that 28345698 or more will not make this work on ALL 6128 :P .
Talking about proof, it would be nice to :
1. identify revision of board that can disable ROM 7 from external extension.
2. Get an updated schematic for these revision.
Lalala... in short: Get a patch for it! :)
Quote from: Munchausen on 14:32, 24 October 13
To add more confusion (or clarity?) to this topic - I have two 6128s here, one of them (an MC0020C) gets the ROM 7 disabled when you connect the LowerROM, the other (an MC0020I) does not.
Can you trace back on the PCB how pin 20 (CEn) and 22 (OEn) of the ROM are driven on your MC0020C ?
From my experience, the Classic boards that have the ASIC/Pre-ASIC always disable ROM7 when ROMDIS is set. But the others (as in this case), don't seem to do it reliably. It doesn't happen everytime, so I have a feeling that it's a glitch due to the layout, rather than an intended feature. I had a PCB here for repair and played about with the LowerROM board a bit. It disabled ROM 7 about 70% of the time. I didn't have time to really intensely investigate it (I had to return the board to it's owner), so I didn't get to the bottom of what was causing it. I assume it's a bus contention issue.
Bryce.
Quote from: TFM on 21:40, 24 October 13
Haha! Oh no! You always refused that possibility completely. But never mind, I can life with that - as good winner ;)
Quote from: TFM on 21:41, 24 October 13
Lalala... in short: Get a patch for it! :)
Well, none of these post helps in understanding how this is working from a logical point of view :(
.... but tells a us a lot about TFM (Who let him escape from the kindergarten ;) )
What a stupid comment! But ok, judge others by talking about yourself.
You talk, talk, talk and talk.... But somebody has to bring it on the point: A patch for all CPCs which enables the external deactivation of ROM 7 would be beneficial. That's the point. And somebody has to state it instead of pussyfooting around!
Now compare both PCBs and you have your patch!
If my theory of how it happens is correct, then it's a fundamental difference in the layout. This isn't something you could could patch. You don't add anything, you just change the physical position of the components, or maybe use a different manufacturer or version of particular logic ICs.
Bryce.
Ok, replacing the SED [nb]and some smaller changes[/nb]is not enough. Well, good to know. So software can care about it. :)
Quote from: TFM on 22:07, 24 October 13
What a stupid comment! But ok, judge others by talking about yourself.
Thanks reminding me not feeding the trolls :-*
Quote from: TFM on 22:07, 24 October 13
Now compare both PCBs and you have your patch!
When I will have MC0020C, I will have a look at it and see is there is a difference at all. However, I am pretty confident that there are none regarding ROM 7 and ROMDIS.
Quote from: gerald on 21:42, 24 October 13
Can you trace back on the PCB how pin 20 (CEn) and 22 (OEn) of the ROM are driven on your MC0020C ?
I put it in storage this afternoon (it is my "best" 6128 - the keys aren't faded at all) but I will get it out and compare it to the MC0020I at some point, maybe next week, I'm away for the weekend.
I'm still not clear on which is the unusual one, the one where ROM 7 can be disabled with ROMDIS, or the one where it can't? I mean, what is the intended behaviour of ROMDIS - to disable all internal ROMs, or all except ROM 7?
Surely a patch could be made just by attaching ROMDIS or its inversion to the enable pin(s) on the ROM?
Quote from: gerald on 21:42, 24 October 13
Can you trace back on the PCB how pin 20 (CEn) and 22 (OEn) of the ROM are driven on your MC0020C ?
I have several 6128s with different PCB revisions, so how would you trace it back?
Would a photo of the underside of the PCB suffice (I am no electronics expert!).
The "Normal" function of ROMDIS in a classic CPC is to disable ROM0 only. The internal ROM7 also uses ROMDIS internally to disable ROM0 when it has been selected. So if you somehow added a wire to make it disable ROM7, then ROM7 would disable itself everytime it was selected. I don't think that would be very useful. :)
The Classic, non-ASIC CPCs that are disabling ROM7 with the LowerROM aren't doing it through ROMDIS, it's happening (as far as I can figure out) due to bits being over-written on either the data or address bus.
Bryce.
Quote from: Munchausen on 23:18, 24 October 13
I'm still not clear on which is the unusual one, the one where ROM 7 can be disabled with ROMDIS, or the one where it can't? I mean, what is the intended behaviour of ROMDIS - to disable all internal ROMs, or all except ROM 7?
Short answer : none are unusual ;) . They both react differently to a same issue.
Long answer :
Well, from a schematic point of view, ROMDIS has no effect on ROM 7 in a 6128 (but also 664 and DDI).
ROMDIS is connected to the FW/BASIC ROM output enable, effectively preventing that ROM to drive the bus when ROMDIS is high.
ROMDIS is also driven from the internal ROM 7 handling logic through a diode, forming a wired OR with external peripherals that must also drive ROMDIS with a diode.
Bryce LowerRom is driving the ROMDIS continuously when enabled. That mean that the FW/BASIC Rom is always disabled, but internal ROM 7 can still be selected and accessed.
LowerRom EPROM is only disabled by extension connected to its own port via a chained ROMDIS, which allow disabling the eprom when a megaflash or like ROM is selected.
So, if you start you CPC with a LowerRom board connected and enabled and no other extension, the FW will start enumerate the ROM. When selecting ROM7, the internal one will be activated as it is not sensible to ROMDIS at all and drive the bus when read.
Here is the issue :
Since the LowerRom eprom is only disabled by the LowerRom local ROMDIS, both eprom will drive the bus (amsdos and lowerRom). This result in a bus contention where result is a mix of pad drive (how strong is the data pad to drive high or low) and a timing issue (who is the last eprom to drive the bus). That can lead to the internal ROM 7 being registered by the FW or not. MC0020C seems to be on the not side.
When adding a ROM board with ROM 7 active, the bus contention will happen between the romboard and internal ROM7.
Quote from: Bryce on 08:22, 25 October 13
So if you somehow added a wire to make it disable ROM7, then ROM7 would disable itself everytime it was selected.
There is a way do do it, but requires a bit to butchery on the PCB ( and have Toto on our back :D ).
Basically we need to insert a diode between the expansion port ROMDIS input and the FW/BASIC ROM. This diode will allow us to differentiate who from the expansion port and the internal ROM7 logic is driving the ROMDIS at IC103 level.
Now can add a small logic that will take the expansion port ROMDIS before the diode and use it to prevent the ROM7 from being selected.
Quote from: redbox on 08:05, 25 October 13
I have several 6128s with different PCB revisions, so how would you trace it back?
Would a photo of the underside of the PCB suffice (I am no electronics expert!).
Tracing back the signal will require a continuity tester as IC may mask the tracks.
Also, since the floppy logic schematic in service manual does not match the schematic of revision MC0020 and upper, tracing back will also involve doing that schematic.
A simple start, if you have a MC0020C, board will be to compare the PCB at track level to any other MC0020 revision board and report differences.
But the easiest way of proving that ROMDIS has no effect on the internal ROM 7 (even on MC0020C) is to use a scope or logic analyser on pin 20 and 22 and see them low even with ROMDIS high !
Great explanation and also an interesting solution to the problem, but it would be quite a bit of PCB butchery, not something I'd want to do to my CPCs.
Bryce.
Edit: Just as a side note. The original LowerROM design isn't from me, it was a commercial product available back in the day. I merely added the feature of having two LowerROM images available instead of the original one and did a new layout. The "ROMDIS always high" is how the original device did it too.
Quote from: Bryce on 10:28, 25 October 13
not something I'd want to do to my CPCs.
Neither do I ;)
Quote from: Bryce on 10:28, 25 October 13
Edit: Just as a side note. The original LowerROM design isn't from me, it was a commercial product available back in the day. I merely added the feature of having two LowerROM images available instead of the original one and did a new layout. The "ROMDIS always high" is how the original device did it too.
Well, I was not finger pointing you, but since I sometimes write lower rom instead of LowerRom, the 'Bryce' force me to think the right way ???
My strange naming system like LowerROM or MegaFlash (with capitals in the middle) probably comes from the mixture of having spoken Irish as a kid (where capitals are possible in the middle of a word) and now mainly speaking German (where words get stuck together to make new ones). Seriously messed up! :D
Bryce.
Quote from: Munchausen on 14:32, 24 October 13To add more confusion (or clarity?) to this topic - I have two 6128s here, one of them (an MC0020C) gets the ROM 7 disabled when you connect the LowerROM, the other (an MC0020I) does not.
Like I said here, 9 months ago, My MC0020C CPC get the ROM 7 disabled when I plug the LowerROM.
You just confirm that. ;)
Hi All
I have just read this all from Page 1 to Page 7 . Phew
Thanks for the info
Ray
Wait, I have the board MC0020C and an X-MEM. You're telling me I can put Parados as real 7 without cutting a trace or lifting a pin? I think I tried putting a ROM at 7 without success before, so I settled for having it in 6th. Is there a special trick for that?
@kahz - et All
I don't know.
My interest was to Put Geralds RamTest Rom in Slot 7 (X-mem) to do some testing.
But after reading the above I am Confused (More than normal)
I will keep looking
Ray
The X-MEM does not support ROM 7. It does support an alternative lower ROM instead.
My CPC6128's actually can software-replace ROM 7. Other CPC6128 seem not to be able. All depending on the board.
@GUNHED (http://www.cpcwiki.eu/forum/index.php?action=profile;u=2029)
Welcome Back.
I would like to Place Geralds " Ramtest " ROM on an x-mem board.
? Where do i place it Please.
It will be used to check a Cpc464.
Thanks
Ray
The RAMTest has to be in the LowerROM position.
Bryce.
As Bryce already mentioned, the lower ROM is the right position.
With ROManager you do the following:
- Start the program, put disc in drive and read directories (go to "File", then "Read DIRs", select drive letter, then press Return)
- Click at "ROM management", then click at "ROM7>lower ROM"
- Then click at "File" and "Load ROM"
- Select ROM slot 7 - this serves for the lower ROM
Any questions? Let me know. :)
Quote from: Bryce on 09:17, 17 November 17
The RAMTest has to be in the LowerROM position.
Bryce.
Thanks I will give that a go tomorrow.
Ray
Quote from: GUNHED on 14:23, 17 November 17
As Bryce already mentioned, the lower ROM is the right position.
With ROManager you do the following:
- Start the program, put disc in drive and read directories (go to "File", then "Read DIRs", select drive letter, then press Return)
- Click at "ROM management", then click at "ROM7>lower ROM"
- Then click at "File" and "Load ROM"
- Select ROM slot 7 - this serves for the lower ROM
[size=78%]Any questions? Let me know. [/size] :)
@GUNHEDThanks for the full explanation.
I am still trying to learn about "LowerROM".
Is there a simple document that explains LowerROM or a link
Thanks again Ray
Well, I would suggest the unofficial Amstrad research pages...
http://cpctech.org.uk (http://cpctech.org.uk)
In principle the lower ROM is located at &0000 up to &3FFF. So when the CPC is switched on the Z80 starts to run at address &0000 and executes the program there. The lower ROM contains the native CPC-OS.
If you replace a lower ROM then the CPC will directly start there at the moment you switch power on. So you can put any kind of testing routines there or what ever you like.
I also made an autostart lower ROM to directly start FutureOS, but I don't use it by myself, because I use the native OS still more often. :-\ :laugh:
Do you need to tweak the rom in some fashion, or basically any rom you dump in that position will boot?
Quote from: khaz on 17:01, 19 November 17
Do you need to tweak the rom in some fashion, or basically any rom you dump in that position will boot?
roms @ &c000 have a header.
rom 0 is special, it is a "foreground rom", other roms (e.g. amsdos) are "background roms".
You *can* make a new rom 0 if you make it a foreground rom.
The lower rom @ &0000 doesn't have a header. If you replace this then you must initialise the hardware (crtc, ppi, z80 etc) and now you have full control. Firmware is not called.
The "LowerROM" hardware from @Bryce (http://www.cpcwiki.eu/forum/index.php?action=profile;u=225) overrides the internal firmware and rom 0. You can then put your own firmware and rom 0, or maybe you want to use a different keyboard language on cpc (i.e. your cpc has English keyboard but you want to use French keyboard. You can put the French OS and BASIC into LowerROM).
X-MEM can override rom 0 too.
See
www.cpctech.org.uk/docs/manual/s158se02.pdf
www.cpctech.org.uk/docs/manual/s158se09.pdf
You make it sound like it's trivial. Am I right in thinking that it could be easily automated? Remove the header, add the initialise code, and you now have a fully fonctional Rom 0 that does whatever it did before, but it boots automatically?
I'm assuming that the header is always the same size, and the initialising code doesn't vary depending on whatever follows it.
Quote from: khaz on 18:03, 19 November 17
You make it sound like it's trivial. Am I right in thinking that it could be easily automated? Remove the header, add the initialise code, and you now have a fully fonctional Rom 0 that does whatever it did before, but it boots automatically?
I'm assuming that the header is always the same size, and the initialising code doesn't vary depending on whatever follows it.
To make it work it all needs code and modifying the roms or making your own.
I'm not sure exactly what you want to do and that makes a difference to what needs to be done.
Which roms are you thinking about?
Standard ROMs are pretty much going to be assuming the firmware exists, so even if you removed the headers and managed to squeeze in enough code to initialise the hardware, they simply won't work without the standard Lower ROM and all the firmware routines it provides. You aren't going to be able to simply make a bootable Protext ROM, for example. The advantage of replacing the Lower ROM is to provide an updated firmware (say a 464 with Basic 1.1 and 6128 firmware) or to provide a completely different OS designed specifically to work in that situation.
Quote from: arnoldemu on 18:20, 19 November 17
Which roms are you thinking about?
None in particular, it was more a general technical question.
In order to boot from any ROM, I imagine would be easier to use a tweaked lower ROM that automatically starts an otherwise untouched ROM at a fixed position.
Bringing this post back to life as it clearly explains what is happening with the CPC Dandanator right now
The CPC Dandanator makes some 6128s unable to access AMSDOS when booting into basic. This is happening because it drives Romdis either 1 or 0, meaning that AMSDOS selection can't disable the FW/Basic ROM when needed and, therefore, causing a brief bus contention during Rom7 initialisation.
The symptoms are already posted in the thread, no RSX commands, CAT responding as Tape....
The solution is changing the Romdis drive to 1 or Hi-Z. This is already done, but it would have saved me a lot of trouble and investigation time to have read this post before.
Thank you all for the explanation and, geez, what a nightmare of a Romdis design within the CPC :picard:
Sorry, i must revoke the old thread, because i have a Question concerning the same problematic (Attention, i'm not a hardware-guy, maybe the question is partially stupid ;) ):
When i have an ROM-Board, which can replace ROM7 on some CPC's (6128), is it a problem, when i try the same thing on an CPC (6128) which can't replace ROM7?
Is there are a chance to damage the CPC? Or the Build-In AMSDOS?
(depends my Question on the exact CPC-Type (464,664,...) ?)
Thank you
SOS
(and still having nice christmas days - whishes to all)
No immediate damage. The only effect is that two devices are writing data to the Databus at the same time. On a system level, this will just make the CPC crash. On a hardware level you are you are causing small shorts between output pins so you may eventually damage one of the ROMs/EPROMs, but nothing else should be effected.
Bryce.
Quote from: SOS on 10:40, 25 December 19
When i have an ROM-Board, which can replace ROM7 on some CPC's (6128), is it a problem, when i try the same thing on an CPC (6128) which can't replace ROM7?
Is there are a chance to damage the CPC? Or the Build-In AMSDOS?
No, that's not a problem at all. It just won't work. But usually most 6128 and all 6128 Plus can do it. :) Frohe Weihnachten. :) :) :)