Challenger C4P estate sale find project

[Dokken]

Thank you Mark!

osi booting.png (3.08 MiB) Viewed 29741 times

[Dokken]

The file DiskTest5.HFE is the only one of the 3 that will boot. the other two files DLR-DEMO.HFE and PLOTBAS.hfe exhibit the same behavior as I had seen before. the TRK display on the gotek will jitter, but nothing loads. DiskTest5 increments the track and loads.

I did test 1 on one of the floppy images. it wrote and read through track 39. it did have a couple of random track errors at different places on different runs.

that's all I've done so far. what does this imply? the separator circuit is working and seemingly timing is correct/close. why would the other two images not load?

I'm gonna let this set as is until I hear back, as I don't want to mess up what I have.

thank you so much, Mark.

edit. image of disk test on a copy of disktest5.hfe on gotek. this time it completed without errors.

[Dokken]

I made up a straight cable, set gotek as D0, a half-height 5.25 jumper as D1. ran the disk test from gotek, changed to select drive B, ran test 1 and it seemed to read/write the 5.25 floppy! this is my ultimate setup, a gotek and 5.25 in the original drive case. This is fantastic and so fun.

still puzzled why the test disk image is the only one of Mark's 3 that will boot.

[Mark]

So I confirmed that my Gotek w/ FlashFloppy booted the Dealer Demo & Plot Basic HFE files I sent you. (My C4P is currently upside down on the bench, which makes it hard to type on, connected to an ancient green screen) It's currently configured with 40K RAM

Dealer Demo

demo.jpg (40.34 KiB) Viewed 29713 times

Plot Basic

plot.jpg (47.14 KiB) Viewed 29713 times

I'm currently using Flash Floppy 3.35 with my Gotek, but it's been stable with older Flash Floppy versions going back years through at least V0.95.25a

Flash Floppy

flash.jpg (30.78 KiB) Viewed 29713 times

The DiskTest disk image uses my own disk loading software "BootThis", not OS65D3, although the disk format is compatible with OS65D. I looked at it in detail yesterday and it ignores the first characters from a track until the start of sector. (Originally it used raw tracks like the boot track, but later I made it compatible with OS65D so the disk images could be copied by an OSI disk copier.)

One difference is disks made with BootThis only use RAM to $2300 or so, plus whatever the loaded program itself needs. Perhaps there is a memory issue in higher RAM? I reworked the OSI Mem Test program as a bootable disk image for C4P. You can use it to test memory above $2000. Upon load the program relocates below $0400 just like the serial loadable version so you can fill/check & test memory above $0400. OS65D starts loading at $2200+ and then relocates to lower RAM, eventually using 0000-$3Axx and higher with BASIC running.

Code: Select all

OS65D File  Track range
-----------------------
  OSI        01 - 02
  C4P        02 - 02
  MEM        03 - 03
 TEST        04 - 04

60 entries free out of 64

OSI Mem Test

TestMem.gif (4.54 KiB) Viewed 29713 times

It's a really tiny <1K test program but it works as advertised to find memory problems. (Docs are included from the serial TestMem program)

So other than that I'm not sure what the problem is. It might be useful to use OSI disk dump or DiskTool to read/hex dump the first few tracks to see what the OSI is actually reading from the disk. Does it see the start of track marker?
Disktool interacts via serial port.

I'll attach the TestMem and Disktool 5.25" HFE images below...

-Mark

[Dokken]

wow, thank you.

I ran t, 2000, 4000. it has been running for about half an hour. X means successful test of that entire range? no errors there?

[Mark]

Yeah, it prints an X when it loops through all possible RAM test values in the specified range. Otherwise an error would cause it to stop & print the address with the read & write values.

Try T:0400,2000 too

To see what it does you can try T:D600,D700 & watch the data shift by on your screen.

When booting, the OSI looks for a change in the track 0 sense line, I think it steps up, then down repeatedly until track 0 active. Once that happens the disk is read. Starting address & pages is read then the specified number of pages are read to $2200 where the data is executed. After that loading continues using the code read from track 0. The OS65D loader reads track 1 with error detection on. If there are errors detected it tries to reread the track. (I don't remember the exact steps the OS65D loader takes, but that could explain the jitter & continuous reads.) The errors detected are parity errors & framing errors. Those could be caused by data separator problems or a clock rate issue I guess. I need to look at it more closely.

When you get a chance, try disktool with HexTransfer to dump the first couple of tracks (or even the whole thing) from Dealer Demo or Plot Basic on Gotek via serial port. (They may not show problems because the don't check for parity/framing errors. )

On boot the OSI will load track 0 and execute it, Dealer Demo (OS65D3) will then load tracks 1 then 6 then 2-6, 12, 14, then 36

BTW, what firmware are you using on Gotek?

[Dokken]

I've tried two goteks. my normal test unit is ff v3.3 and has the small led text display. I also have a new one with the latest (today) ff version. the new one still has the 7-seg displays which doesn't show version. BUT, with the 7-seg display, I do see the non-working images go 1, 2, 3, 5, 6, 4....does seek some tracks before stopping/not loading. I was not able to see this count on the text display...guess it is too fast. but in the end, same result, only the two special ones you made will boot.

T 0400, 2000 shows this:
T:0400,2000\ IC01 IO IC.
then the machine locks up.

Screenshot 2023-03-07 at 2.34.43 PM.png (3.56 MiB) Viewed 29704 times

T:D600,D700

Screenshot 2023-03-07 at 2.36.33 PM.png (3.73 MiB) Viewed 29704 times

I have yet to try to get the serial connection working again. I am pretty sure I have the proper cables and null modem cable now. I can dig those out if needed.

[Mark]

T:0400,2000\ IC01 IO IC.

I think that means it wrote $10 but read $1C at $1C01
Look like bad RAM at $1Cxx -- a single bad 2114 or bad chip select/dirty socket?
That would cause OS65D to fail to boot.

Upon error, I think you can press return to restart Memory Test.
You can use F: command to fill memory and C: to test memory.

Or in OSI monitor you can type .1C00/ and enter values & see results.
Perhaps fill 1C00-2000 with 00 and compare, then FF and compare?

The SAMS C4P service manual can help you locate the bad chip.

[Dokken]

fantastic!

I'll dig into this tomorrow. I think I have some 2114s.

[Dokken]

Rewind a couple of weeks and it was suggested I had a bad RAM. I tested every 2114 on the RAM board by using a Commodore 64. The early C64 uses a single 2114 for video RAM. I socketed that and kept swapping until I found the one which resulted in a distorted video output. I also have a backbit.io chip tester which will test a variety of chips including 2114, and this bad chip tests ok in that. odd. but I replaced the bad 2114 and had to sit this project aside due to work.

I have this unit pretty much disassembled on my bench so I can get to everything easier out of the case, and am using a 5v modern supply.

Whelp, I had some time to look at the C4P again today. And another problem. it will not reset with the break key. Garbage stays on the screen. The break key seems to simply ground the reset pin on the 6502.

Clock is present, and there is a probe signal on all address lines, so I'm hoping it is still basically functioning. I've poked around on the other chips and I do see activity.

Any tips for how to diagnose why this thing will no longer reset to the D/M/? prompt?