6502.org

Hello,

In my first post to this forum I'm asking for some help and data

In a mood of nostalgia I have brought my old EC65 (Octopus 65, Samson 65) to live. Or more or less.
The computer itself works. It's just the floppy disks (OS65D) worked first. That was a surprise, considering the 35 years of not using them. Then they stopped working. All of them. Could be an indicator of the floppy drive failing, but this needs more investigation.

In an effort to get this system working reliably, without having to buy 5,25 disks or old floppy drives I thought about putting all the data, as far as I could get it, into a flash and access that. But that requires some changes to the monitor/bios.

Does anyone have the source code/assembler file of the monitor?

Alternative option would be using a floppy emulator (HxC), but I'm not sure, if that would work with that strange floppy format of the original FDC. Any experience or hints in this regards?

Welcome, tanteju. Which option to you intend to pursue? If you intend to try to get the floppies working again then it'd be helpful to provide more detail. Do the drive motors turn? Is there an error message that appears? Can you confirm that all power supply voltages are present?

cheers,
Jeff

Welcome tanteju!

There is some info and a download on Hans Otten's site:
http://retro.hansotten.nl/6502-sbc/elektuur-junior/
BTW, for floppy emulation, if you try that, the Gotek product with the open source FlashFloppy firmware might be a good choice.
https://github.com/keirf/FlashFloppy/wi ... patibility
https://www.youtube.com/watch?v=_0E6v7KVNk8
(I'm not sure if Gotek and HxC are exactly the same thing, or related, or just have a similar function. But I don't think the original HxC firmware is open source.)

Thank you for the warm welcome.
Considering that 5,25" disks are hard (aka expensive) to get, I'm in favour of a floppy emulator. But, on the other hand, why am I doing all this? Just for nostalgia. It is not the processing power nor the memory or the graphics capabilities. Maybe the really fast boot times, but ok. And if it is nostalgia, it should work with floppy disks

I've tried with two disk drives (all I have) and the disks now fail in both drives. I've just measured. Rotation speed is 300 rpm (measured via index pulse) and data signal is coming in. So, the drives seem to work. It worries me a little bit, that I instantly made a copy of the one working boot disk and even that copy now fails.

But, on the other hand, even if I would get the floppies working, I need to get data on them. Therefore I need to write a program and make use of monitor routines. I think getting the source of the monitor is more or less inevitable.
The Junior, which I rebuilt last year as my original one got lost in the weeds of time, is perfectly working with exactly that ROM image. But the EC65 has a 4k ROM (2732). I have the image (first thing was reading out all EPROMs and saving the images), but for modification a little bit more information is needed. I could do that on my own but I hoped, someone else did so before and would share the results.

In addition the original OS65D required some changes to work on the EC65. And Elektor provided one special disk, called "LOYS" (after nickname of A. Nachtman I assume). Could not find any image from that disk and mine was not readable at all.

Regarding the floppy emulator I might give Gotek a try then.

Hi Tanteju and welcome,

Found this on archive.org and it may be helpful: https://web.archive.org/web/20140115044 ... rg/osiweb/

Cheers,
Andy

Found an old commented disassembly of OS65D 3.0. If nothing else works, I will have to use that.

But still looking for proper disassembly of the EC65 monitor EPROM. Could not find anything so far.

Please do share links to any findings.

I found this post elsewhere by hoglet:
https://stardot.org.uk/forums/viewtopic ... 889#p88889

No links to share, but a lot of findings:
1. Several strange effects are a result of something broken in the electronics. I assume, it is a capacitor, but I could not find it so far. Result is that read/write to RAM card does sometimes not work properly. CPU, VIAs, Bus drivers on CPU card already changed, with no effect. Phi2 does not look great, but with an external static RAM card that should be no issue. Maybe a capacitor? I will probably change all of them. But that takes time. In the meantime I found a configuration, where it mostly works.
2. I've managed to get an OS65D 3.3 booting properly from Gotek drive. But writing on Gotek does not work so far. That is actually investigated. I'm not sharing the image publicly so far, because some tools on the disk still need patching.
3. I've disassembled the SAMMON myself about 95%. See attached file. Some notes on this one:
- It is from first version of EPROM. I've found that a second version exists, which uses some procedures at D800. Could not find any documentation about what is supposed there.
- All uppercase labels match original documentation as far as I found it. Lower case labels are made up by me
- I've not commented the disassembler piece. Did not get the logic in there so far and did not want t spend more time on that one.
- The original documentation said, that the VDU card not be programmed via jumper, which is not correct. The EPROM routines load configuration for some VDU modes if jumpered.
- assembler to be used is da65. I've double-checked and it assembles byte right

Thanks for sharing your efforts! Nice monitor: smart VDU output, facilities for Basic, simple monitor with disassembler, ability to boot from floppy.

I found this, which might be one of several articles on EC65:
https://archive.org/details/kim1_De_uP_ ... 1/page/n27
"De uP Kenner.61" April 1989

That's funny. I scanned up to issue 58. Thanks for the hint.

Hi, tanteju. You used the word "sometimes," seeming to indicate an intermittent problem. Such problems are very commonly caused by different kinds of bad connections, and only rarely by defective IC's or capacitors. Sadly, this means the repair efforts you describe probably won't bring success (and indeed, there's a certain risk of accidentally creating new problems).

Bad connections take many forms, including (to name just two) poor solder joints and tarnish/oxidization on the tiny metal inserts which are part of IC sockets. There are ways of dealing with this sort of thing, and it'll be helpful to provide as much info as possible, including photos, schematics, and a more detailed description of the failure. Eg: are all bits affected? All addresses? Also, does physical vibration seem to change the behavior?

cheers,
Jeff

Hi Jeff,

It all started with adding another (really old) floppy disk to the power supply and starting to copy from one drive to the other. This power surge resulted in one RAM (4164) to fail and the VDU card now having drop outs on the screen. In addition Phi2 is so weak, that timing measurement, even with high impedance probe, is not possible. As soon as the probe is attached to Phi2 on the bus, VDU card stops working completely. Hence timing measurements on the VDU card do not really work well. I have built a RAM card with static RAM, to verify it is not the dynamic RAM card. And even there I noticed that RAM cells behave "strange". Strange means, writing FF does in some random cells either have no effect or it is DF or 3F and even when just reading the same cell the values change.
As this is with both RAM cards and without FDC card, there are only two cards left: CPU card and VDU card. And as it occurred from one moment to the other I doubt any weak contact in a socket or so. Especially as I have replaced all driver chips on the CPU card so far.

Schematics for both cards are attached.

Hi, tanteju.

In addition Phi2 is so weak, that timing measurement, even with high impedance probe, is not possible. As soon as the probe is attached to Phi2 on the bus, VDU card stops working completely.
On the EC65 CPU card, the PHI2 signal for the bus is generated by pin8\N70\IC20\74LS05_or_74LS06,
which has an open collector output. R13 works as a 470 Ohm pullup resistor to +5V for PHI2.
PHI2 goes to pin 27a on the bus connector.

On the VDU card, pin 27a of the bus connector is labeled "E" (68xx style),
goes to pin2\N24\74LS00, pin13\N26\74LS00, pin23\IC11\6845.

_Where_ did you probe PHI2 ? On the CPU card, or on the VDU card ?
Are you using passive 10:1 probes ? When attaching the probe, is PHI2 always HIGH, or always LOW ?
To me, it feels like the PHI2 line could be "broken" somewhere on the way... most likely by a defective backplane.

Try to solder a wire from pin8\N70\74LS05 on the EC65 CPU card to pin23\IC11\6845 on the VDU card or so.
If this doesn't help, check if the pullup resistor R13 really pulls up.
If this doesn't help, check all of the connections on the PHI2 line in the computer for an open connection with a multimeter.
If this doesn't help, check if there are other PCBs (which might cause trouble) plugged into the backplane.
If this doesn't help... try to replace some of the chips.

Good luck !

On the EC65 CPU card, the PHI2 signal for the bus is generated by pin8\N70\IC20\74LS05_or_74LS06,
which has an open collector output. R13 works as a 470 Ohm pullup resistor to +5V for PHI2.
PHI2 goes to pin 27a on the bus connector.

On the VDU card, pin 27a of the bus connector is labeled "E" (68xx style),
goes to pin2\N24\74LS00, pin13\N26\74LS00, pin23\IC11\6845.

_Where_ did you probe PHI2 ? On the CPU card, or on the VDU card ?
Are you using passive 10:1 probes ? When attaching the probe, is PHI2 always HIGH, or always LOW ?
To me, it feels like the PHI2 line could be "broken" somewhere on the way... most likely by a defective backplane.

Try to solder a wire from pin8\N70\74LS05 on the EC65 CPU card to pin23\IC11\6845 on the VDU card or so.
If this doesn't help, check if the pullup resistor R13 really pulls up.
If this doesn't help, check all of the connections on the PHI2 line in the computer for an open connection with a multimeter.
If this doesn't help, check if there are other PCBs (which might cause trouble) plugged into the backplane.
If this doesn't help... try to replace some of the chips.


Hi,
Yes, checked the Phi2 signal with a 10:1 probe and it looks the same from N70 on the bus card up to VDU card. Swapping 74LS05 does not help either.

But I noticed:
- There are no errors on the RAM on CPU card, although it is behind the same drivers
- The likelihood of errors on RAM rises with number of 1 bits in address, but with some strange importance of A5-A7. There are never errors in D700-D72F but D730-D7FF hs now and then errors. D800-D86F does not have errors, but D870-D87F errors again. Not always the same bytes. It varies.
- Errors could be reduced by terminating address bus on backplane with 2k2 to GND
- Read errors mostly occur after write access to CRTC on VDU card (e.g. cursor update)

Bus drivers, RAM, EPROM and CPU on CPU card are already replaced. IC2 on VDU card replaced, as that serves A4,A5,A7 which are used for address decoding for $E140 (CRTC address) and N16, which is used for data drivers of the VDU card.
But while I'm writing this I think I have missed something important. My test routines did not directly write to CRTC but used EPROM routines ... Maybe I should check IC17 on the CPU Card, if the EPROM select has issues for whatever reason.

Many years ago, I had a defective backplane which had prevented a computer from working for good.
But I wasn't aware from the start, that the problem had been caused by the backplane.

Does your backplane look like this ?
If yes, plug the PCBs into a new backplane, and see what happens.

;---

Nice green solder resist on the backplane PCB, that yes, but no copper inside the holes.

When soldering the connectors into the backplane, _then_ mounting the connectors with screws to the PCB,
this causes mechanical stress to the pads where the connector pins are soldered.

Could happen, that some of the PCB traces "go lose" from the pads after a while...
...when an old school floppy drive decides to send vibrations through the whole computer, for instance.

Would be good to know for sure that the malfunction isn't caused by "a simple mechanical problem" before digging deeper into the hardware.