Currently I am building simple, modular 6502 computer. At this point it runs EhBasic using serial terminal.
At this point my main goal is to configure and run peripherals on my I/O board - beside UART there is a GPIO, timer, 8242 keyboard controller and CF card slot. Yesterday I decided to try with a Compact Flash card.

Card socket is connected directly do the system bus (I have an additional logic generating !RD and !WR signals for Intel bus devices), according to schematic from this page. Everything works fine when the card slot is empty. But when I try to power the computer with the card inserted, it doesn't work. There is either nothing or some random characters on my terminal, instead of standard EhBasic cold/warm boot message.

At first I thought that it might have been because uninitialized card, so I put proper code (initializing card in 8bit mode) at the beginning of EhBasic init section. I didn't change anything.

I checked it with two SanDisk cards. First one is plain 1GB model. The second one is an industrail grade 32MB model. Neither of them works.
Any idea what may be the cause of this weird behavior?

Hi, Atlantis. Congrats on getting EhBasic running!

As for the Flash problem, the behavior you describe could be caused by improper chip-select to pin 7 of the Compact Flash card, resulting in it being active at the same time ROM or RAM is active, and thus interfering. What sort of address decoder have you provided to generate the chip-select? And do you have a 'scope or logic probe with which to observe the chip-select signal?

There are other possible causes, of course. What's the clock rate of your computer? Have you provided bypass capacitors? And what's the construction technique -- are you using a solderless breadboard, for example?

A schematic and some photos would be helpful. (And this is a good time to remind everyone that when you post on this forum you're allowed to attach images. This is a more convenient solution than posting the images on a third-party site, and it's also more permanent.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Following Jeff's idea... you could easily tie /CS0 high (bypass your select logic) and see if you still have a problem. This would simply have the CF card on the data and address bus, along the WR and RD signals. If your computer still doesn't power on, then you likely have a problem with the data and/or address lines.

_________________
Regards, KM
https://github.com/floobydust

Can you reset your board? It's possible power-on reset is broken with the CF card in, but a re-reset will work. On similar lines to above, check your power rail voltage and your bypass capacitors - the CF card might be very demanding or very noisy on the rails.

Im my design there is 8kB of I/O address space. It is divided by 8 by one 74HTC138 chip on my CPU board. Its CS signals are connected to the bus connector, so I can redirect them to the addition boards. The idea is to provide additional 74HTC138 chip on each board. This is the case with mentioned I/O board, which (among others) consists CF card. Decoder seems to work fine, because it also selects other I/O devices, such as UART or RTC which were at least partially tested. Only CF card causes problems.
I measured voltage at CF CS line when card should be inactive. It is 5V.



Now it is 2MHz. I can be clocked down to 1MHz if necessary.



Yes. There is 100nF capacitor near to VCC pin of every chip. Including CF card - in this case there is only one, because two VCC pins are close.



It is mounted on two homemade, one sided PCBs. Here are the photos and schematics.

Could it be the NMOS CPU and a CMOS CF disagreeing about voltage levels ?

Maybe, but I don't think so...
1) There are 74HCT245 chips buffering address bus just before system bus connector (memory chips are connected directly do CPU).
2) Address decoding is done with HCT chips.
3) !RD and !WR signals are also generated with HCT logic.

So only data bus is not buffered.
Memory chips are also CMOS, there is no problem.

I am not the first person who uses CF card with retro hardware...

What kinds of tools do you have for investigating? Logic probe, oscilloscope, bus pirate, logic analyser...

At home I have only cheap Chinese USB logic analyzer, 8 channels if I remember correctly.
I can use proper digital oscilloscope, but it requires visit in local hackerspace.

Answering earlier question: I tried to manually reset computer. It didn't help.

Even with only 8 bits of data capture, it might be useful to watch the databus for a few tens of cycles after reset. And then watch some control signals and then some address bus signals. That is, see if the CPU is executing code at all, with the CF in place. Of course, you can compare traces with and without the CF. (If you have only 8 bits, you might want to capture clock and sync and read-not-write together with a nibble of the databus, and then collect the other nibble in a second run.)

If you can manage to collect a bit more than 8 bits of data capture, I very much recommend using hoglet's decoder:
https://github.com/hoglet67/6502Decoder/wiki
viewtopic.php?p=60330#p60330

If your I/O select is high on the CF card, then you might want to use a logic analyzer or scope on the data and address lines to see if one or more are getting locked into a state.

Also, your posted CPU schematic PDF is the same as the I/O schematic, except that part of the right side dropped to a second page.

_________________
Regards, KM
https://github.com/floobydust

My mistake. Here is the correct schematic of my CPU board.
BTW maybe it is in fact a power issue? Maybe 100nF bypass capacitor isn't enough and I should add some 22-47uF tantalum in close vicinity of CF card?

Nice looking project!

As for troubleshooting, floobydust had a good suggestion. "you could easily tie /CS0 high (bypass your select logic) and see if you still have a problem. This would simply have the CF card on the data and address bus, along the WR and RD signals. If your computer still doesn't power on, then you likely have a problem with the data and/or address lines."

Given that two different memory cards produce the same result, this might seem like a pointless exercise. But IMO it's still worth doing.

BigEd also had a good suggestion, but IMO it's best to try simpler measures firstly.

Thanks for providing schematics. Can I suggest you alter them to better identify the chips? "IC3" or "U$1" doesn't necessarily mean much to me! Ideally, an actual part number would be included, and/or a comment such as "keyboard controller" etc. Also, it'd be appreciated if the schematic can be rendered in monochrome, as some people have difficulty reading schematics that use color.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

A power problem could cause issues. Being able to accurately measure voltages on both boards and at all chips would help to ensure you're not having a voltage level drop low from the additional load of the CF card. Also, bypassing... it can't hurt to add some additional filtering directly at the CF power pins. what is the power supply rated at?

Also note that the DS1813 reset chip comes in several trip levels, i.e., when the voltage gets too low, it holds the reset low. Check which one you're using and ensure it's coming off reset.

For examining power lines, an analogue scope is just a very handy tool, as you can easily see any noise, etc. that is on the power lines.

PS - agree with Jeff... nice looking project

_________________
Regards, KM
https://github.com/floobydust

I already tried several different solutions:
1) Trying yet another CF cards, including 1GB Kingston and even 4GB Seagate Microdirve HDD.
2) Adding 10uF monolithic + 22uF tantalum capacitors near card slot.
3) Using fuse rated for larger currents (in case if there was a voltage drop)

I've found article which mentions similar problem:
https://ciernioo.wordpress.com/2015/02/ ... face-card/

Maybe it is in fact caused by the lack of buffer on the data bus? Maybe I should design CF card module with proper buffering?