FlashGordon - new batch

[Bryce]

Hi!


Well I'm still reworking the schematics


I fixed two problems with the original MegaFlash address decoding support: lack of decoding for the A14 address bit on write access, and use of diodes for logic. If you know something about these things, let me know what you think of the attached schematics. Otherwise, enjoy the 3D renderings!


As a bonus, there is now enough space for a proper reset button (maybe not so useful if you have a Mother X4 board, but quite nice otherwise)


I don't know if I can start manufacturing these in the current situation, and I need to do some tweaks to the PCB anyway (making sure the holes for the write protect switch are at the right place, for example).

As the original designer, I know a little about both things I used diodes to handle the logic because I had run out of gates and two diodes were cheaper and needed less pcb space than adding another chip. As for not decoding A14, I didn't consider it necessary at the time. There was no combination of hardware that would clash with it.

Nice layout by the way, I like how much you've reduced the PCB size.


Bryce.

[GUNHED]

Sorry, but for A14 there is lots of stuff, see CPC I/O list. IMHO it very important to always fully decode all 16 bits.In addition is a pain from the software makers POV. But it works, and thats great.

[PulkoMandy]

Well, everyone has been using the MegaFlash and FlashGordon with this limitation and no one ever complained (to me, at least?).


This is for memory-mapped access (writing to the ROM) not for IOs. And it does something only if you follow the very specific sequence of writes needed to do a write access to the ROM, so it isn't too bad. I've been using my FlashGordon for years with this and never had a compatibility problem. But still it is a little thing that annoyed me in the design. Yes, I guessed that it was due to wanting to keep the board reasonably small and simple and not adding an extra chip to it (routing the PCB was already difficult enough). And as I was reviewing my old schematics and making plans for new projects this week I had this idea of using 74LS138, it is useful to compare 6 bits to almost any given value. Not the most efficient use of PCB space (half the pins of the chip are unused) but at least it directly decodes 6 inputs into one, and I don't have to route tracks back and forth between two chips.


We'll see if I didn't mess up anything and this actually works when I receive the PCBs.


Mh... I think I could even easily make it be ROMs 32-63 for people who think 32 ROMs aren't enough and want to use two of these side by side...

[GUNHED]

It always depends where you have your stack. Also interrupts (in IM 2) can be source of troubles.
Furthermore the chip has a software protection. Sometimes one loads a picture and it has Byte &55 at the wrong position, also this can cause troubles.
As long as we know that A14 is not decoded, it's not a problem to work around. 


Sorry for my comment with the I/O range, this was wrong an misleading. 

[gerald]

Hi!
If you know something about these things, let me know what you think of the attached schematics.

1. I am a bit puzzled by the decoding using the 74LS138.
The way it is wired your FLASH will only be selected for ROM number 32 with R0EN connected to U3_Q0, and never selected if you connect R0EN to VCC.
I you keep U5 input as such, you should use U7_Q3.

2. I don't think you need R5 nor R3. Even R4 is not needed if you use 74HC00 or 74HCT00.

[PulkoMandy]

R5 forces R0EN to 0 when the jumper (SW3) is removed. It allows to disable all ROMs in case something goes wrong and you want to boot the CPC with the device connected, but disabled. Then you can run some ROM manager, put the jumper back, and reprogram the broken ROMs. This was missing from the original MegaFlash and documented as a mod for it in the wiki when I did the first version of FlashGordon (now the wiki describes a different mod, adding a push-button instead)


And yes, U5 Q3 should be used, of course, thanks for catching this! I think I swapped the inputs around while doing the routing and forgot to adjust the outputs 
I'm considering adding a switch to allow selecting Q3 (ROMs 0-31) or Q7 (ROMs 32-63) in case someone would want to have 64 ROMs on their system.


I don't know about R3, that's from the MegaFlash design (as seen here: http://www.cpcwiki.eu/index.php/MegaFlash). And yes, I'll use 74HCT chips (I had compatibility problems with 74HCxx in the first FlashGordon batch however) so I can leave R4 out. But I'm leaving the footprint in case someone wants to assemble the board with 74LS chips.

[gerald]

R5 forces R0EN to 0 when the jumper (SW3) is removed.

Ok, the schematic made me think that SW3 was an actual 2 position switch, not a jumper (poor man 3 position switch  )

[RetroCPC]

If you know something about these things, let me know what you think of the attached schematics. Otherwise, enjoy the 3D renderings!

PM,

Sorry for the off topic question, but I noticed your using KiCad, how do you find using its UI? I'm sadly using Altium thesedays but its UI is so terrible - I'd hoped I'd get used to using it with time, but its so awful I still dread having to use it...

Its intelligent track place (as your manually try to route a track) is on drugs, goes ANY direction but the one you want - I don't understand why its so invasive... its so complicated to delete / move a track... everything about Altium is needlessly complicated - my life too short to fight such CrXP

For simpler PCB's and Spice simulation I still use Labcentre's Proteus - IMO it has the simplest, best, most logical UI... not sure if you have any experience with Proteus - but how do you find working with KiCad? 3D is not important to me - I like to essentially manually route my PCB's... Place a track - route manually node to node without any stupid invasive "interference" from the software...

If you have watched any YouTube videos where they are teaching users Altium you will see them repeatedly trying to place a track, deleting track sections and trying again as Altium send the track in the opposite direction of where you wanted to place it... These are Pro users, so its not just me with my "lack of experience"...

[PulkoMandy]

Hi,


Well I have never used Altium, so I don't really know how they compare. It woudl seem that Kicad in recent versions behaves as you say, trying to autoroute things in stupid ways and making it annoying to delete these traces. Old versions did not have any autorouting, and that was perfectly fine for such simple projects. I didn't look yet if there is a way to disable or configure it. At leat it previews things in realtime so you can see it's going stupid before you actually place the track, so you can press escape and try again. And keyboard shortcuts help quite a lot in getting things done (backspace or delete to remove a track, etc).


It reminds me of a story about my father. He worked in a print shop and used a tool to cut vinyl stickers (to make big lettering to put on cars and trucks and the like). He used a tool from the 90s that ran on Windows 98. The machine required 3 parallel ports for driving the cutter, printer, and for the software protection dongle. At a time the company bought a new, larger, faster machine. It came with a new tool, but it seemed the tool was needlessly complex and made things 10x more difficult for no reason. He then got a training on it, and came back conforming that the tool was indeed bad designed, it was not just missing knowledge on how to use it.


And so until two years ago when he retired I helped keep that Windows 98 machine alive and connected to the company network so he could send files back and forth to it to use this old but efficient software. It was not always easy to find spare parts still compatible with it and getting windows network shares to work was a bit of a challenge sometimes, but it did work!




Well in any case, now that I know how to use Kicad I don't really plan to switch to something else, so I guess it's good enough.

[RetroCPC]

PM,

Thank you for your swift reply - sadly it seems like KiCad are following Altiums footsteps... trying to be a "Free" version of Altium

WRT Labcenter's Proteus, I'm in fact using an earlier version (Aries 6.9) which runs under Windows XP - LabCenter had to rewrite later versions to support the new Graphics drivers in later Windows versions - in rewriting the software they made it worst... although its still leagues better them Atlium IMO.

So I understand your pain of supporting an even earlier version of Windows...

Sending my love to France, I lived there for many years (and in fact I met my Wife in Paris). I still miss the lifestyle - although not trying to run any kind of business in France!!!

[sfox72]

Hi,
is it possible to join the list, or is the batch already closed?
Stefan

[PulkoMandy]

Hi,


I have finally ordered the boards. Since I made quite a lot of changes to the schematics I ordered only 10 boards for now. I will check if this new design works. If it does, I can make another batch. Now waiting for the PCBs to get delivered so I can start assembling and testing

[GUNHED]

Hi there,
Well, I assume the new batch will use Flash Chips from SST or Winbond (as before), if not let me know.


Today I will upload a new version of the ROManager 2.34 for all ROM simulating devices for the CPC / Plus range. Links see below.

[PulkoMandy]

No change of flash chip. The reason I switched to the SST one in the first place (compared to the original Megaflash) is that it's still in production, so it's easy to buy when I need it. So far this has not changed, so everything is fine

[GUNHED]

No change of flash chip. The reason I switched to the SST one in the first place (compared to the original Megaflash) is that it's still in production, so it's easy to buy when I need it. So far this has not changed, so everything is fine

Thanks for you answer. Great! BTW: Using SST for this reasons is of course the right decision. Why using a chip which is no longer available. I hope you will sell lots of your great device. 

[Bryce]

The W27C040 that I used on the original MegaFlash was widely available at the time and it had a few advantages over the SST part. That's why it was chosen. Unfortunately they became more difficult to source soon after that, but they are still available, even in large quantities.

Bryce.

[TotO]

The Winbond EEPROM advantage compared to the SST FLASH is the 256 bytes pages vs 4K pages and the fastest writing speed.
The most inconvenient is that it require each time to manually lock/unlock to be sure to not loose data.

[Richard_Lloyd]

Hi. If there's one available from this or a future batch I'd like to put my name down. Many thanks.

[Nitro]

@PulkoMandy: if there is such list, could you put me on it as well for one item?

Thanks!

[GUNHED]

The Winbond EEPROM advantage compared to the SST FLASH is the 256 bytes pages vs 4K pages and the fastest writing speed.
The most inconvenient is that it require each time to manually lock/unlock to be sure to not loose data.

Yes, the Winbond is more of a beauty. However since we usually burn 16 KB blocks, the page size doesn't matter. (It would matter as soon as we would use a ROM floppy though).

About writing time. Since we do not write too often I personally don't care if it takes half a second or one full second to burn a ROM. (And yes Tot0, you're right, there can be application in which time will matter).

The MegaFlash from Bryce uses the Winbond, and it can be protected by software, so it's not needed to use a switch. The same is true for other devices, except the bright blue LED is not there.

For the devices supported by ROManager this software protection does work for all Flash chips. None of the devices actually needs a switch being moved (when using Flash software-protection).
Having said that, it may well be possible that one feel more save with using a switch too.

In case your device is in Write mode all the time, then the Flash can be identified by software, which is cool! 

[TotO]

The MegaFlash from Bryce uses the Winbond, and it can be protected by software, so it's not needed to use a switch.

The first X-MEM used it too. But, the soft protect of Winbond EEPROM is not enough robust to avoid accidental data lost if not hard protected.

[GUNHED]

The first X-MEM used it too. But, the soft protect of Winbond EEPROM is not enough robust to avoid accidental data lost if not hard protected.

I never had that problems. Lucky me. 

[Bryce]

The same is true for other devices, except the bright blue LED is not there.

Your MegaFlash was a "Blue LED limited edition" because you requested it, no one else had a Blue LED.

I decided on the physical write switch because there are so many situations that could accidentally corrupt the data. Having a physical write switch meant that no bit combination on the expansion bus can damage the data.

Bryce.

[GUNHED]

Yes, that's right of course. A switch is a good thing to have. Just to be sure. Even if I never use it, I fell better just by having it. 

[PulkoMandy]

With the sst flash you need, not just some data on the bus, but activating two different roms in sequence and writing exactly one byte to each of them, without any other rom access in between.


So, yes, in a lot of cases the software protection is enough because this is quite unlikely to happen by accident, and the write switch is just to be extra safe.