Top drive, drive-enable (2).
Quite simple, bus bit 1 driven high, encoder chip 44 (74138) given 3 bit code, drives CLOCK one state over on chip 17, copies bus bits to output, drive latches on.
Need to draw the rest of the board but this bit is enough for tonight.
Phil
There's a later model AES i/o board on eBay- well, was. It's just been purchased.
It should serve as source of spare 74xx logic and most importantly the SMC COM2601.
I looked and that chip has Vcc and Vdd power- it will have been run without Vcc which won't have done it any good at all.
I'm working on the logic layout right now for all the different floppy drive functions.
Phil
I admire your persistence. I think most people would have given up on the project long ago.
Hope your effort will soon be rewarded with a working AES.
With your discs, that made the prospect of this machine working again viable!
I enjoy the challenge. It's helping me understand the computer better, which is something I like. Years ago I took a class which involved troubleshooting at this level and writing Z80 assembler, but my understanding of the processor and the rest of the system attached to it was limited as it was a rapid class.
This has given me that opportunity again to try determine what's wrong, and in doing so, expand my knowledge.
Phil
3x 7406 bad (floppy drive drivers, ooen collector Schmitt NOT)
1x 74121 monoflop bad
1x NE558 monovibrator bad
1x 74374 flip-flop bad
I think the power supply failure took out a bunch of TTL. Adding to the list as we go.
Unfortunately that had little effect upon the overall behavior of the computer.
However, one thing to note was when it did decide to beep, it was with a very clear tone. No crackles as it was doing before (switching the beep on and off very rapidly by the sound of it).
What I am doing is trying to make a photographic record of what printed wire goes where. This side of the board they've generally kept to vertical traces, the back side horizontal. There are many vias which makes tracing them awkward but I'll do my best to create a schematic of at least the CPU and I/O boards to begin.
Phil
Well, I have had some sleep and come back to the boards.
I removed the 74121 from it's socket (61) on the I/O board and set it to test on my prototype board.
Dead! No Q or !Q so that needs replacement.
It's tempting to jumper !Q high on the board, plug it back in and see if it freaks out...
Phil
USRT (!) COM2601
https://datasheetspdf.com/mobile/1412055/SMSC/COM2601/1
Einen WD1660 kenne ich nicht. Vermutlich ist der WD1770 gemeint...
Did I menition I've had about 9 hours of sleep since Sunday?
Yes, WD1770.
I'm going to stop typiing until I've had a rest!
74LS123 twin monoflop testing.
Phil
Alles anzeigenThe letters have worn off chip 56 on my I/O board (950-008901)- can you check what type of chip is connected to yours please? (No hurry).
My AES is well stowed away at the moment, it would probably take a week.
Take these HiRes photos, they also helped me identify my ROM types.
PIC: https://vintagecomputers.sdfeu.org/aes/pics/fdc_printer.jpg
Site: https://vintagecomputers.sdfeu.org/aes/
According to the photo it's a NE558N Quad Timer
and if you need a new COM2601 USRT with 60! Days Warranty
:
https://www.ebay.com/itm/20213…f77a5b:g:-q4AAOSw-09aIKyu
PAW I was discussing this on the VCF with Chuck G and he said:
Using a USART chip for an early FDC would not be uncommon. I'll have to go back to my notes on an early 8" AES disk to look at the encoding, but I do recall that the bitstream was USART order, not traditional FDC order. Using asynch I/O would seem to be a horrible waste of resources, however.
Has he made a correct assumption, that the data is stored not in a standard WD1660 style format?
I am convinced that the 8" AES floppy disks have a completely different format and are therefore not comparable with the 5.25" AES floppy disks.
If you look at the explanations of the developer of the FluxENGINE, then even for his assumptions there can only be meant an 8" floppy disk. (77T, 32 Sectors).I think his basis was an image of an 8" floppy disk and according to his investigations it should be an M2FM encoding with bytes written backwards. But maybe we'll find out more when I hold Martin Hepperle s 8" disks in my hand.
The 5,25" Disks on the other hand are FM encoded but PAW knows the details of the 5.25" disks much better.
Here are the explanations from the FluxENGINE page. ...as I said, it has to be 8" because there are no 77T 32Sec 5.25" hard sectored discs.
8080 machines with 32kB of RAM, they ran their own proprietary word processing software off twin 5.25” drive units, but apparently other software was available.
The disk format is exceptionally weird. They used 77 track, 32 sector, single sided hard sectored disks, where there were multiple index holes, indicating to the hardware where the sectors start. The encoding scheme itself is MMFM (aka M2FM), an early attempt at double-density disk encoding which rapidly got obsoleted by the simpler MFM — and the bytes are stored on disk backwards. Even aside from the encoding, the format on disk was strange; unified sector header/data records, so that the sector header (containing the sector and track number) is actually inside the user data.
NE558N, thank you!
I have had such a busy week with not enough sleep! I'll get some good rest and read thoroughly.
Phil
mister-freeze I need a favor!
The letters have worn off chip 56 on my I/O board (950-008901)- can you check what type of chip is connected to yours please? (No hurry).
Thank you
Phil
PAW I was discussing this on the VCF with Chuck G and he said:
Using a USART chip for an early FDC would not be uncommon. I'll have to go back to my notes on an early 8" AES disk to look at the encoding, but I do recall that the bitstream was USART order, not traditional FDC order. Using asynch I/O would seem to be a horrible waste of resources, however.
Has he made a correct assumption, that the data is stored not in a standard WD1660 style format?
A long week so far with inadequate sleep. Yes, it is a 3-bit binary decoder.
Cracked or not, the 3-bit binary to decimal converter still functions correctly.
On to the next one.
Philip
I saw something hitherto undiscovered this morning- one of the 74LS138 binary to decimal converter chips that interfaces directly with the UART on the I/O board of mine is cracked.
That would cause the behavior of the I/O board to be highly disruptive if it has failed. I shall use it as the first suspect on that board.
Phil
It would be nice to know the system addresses now.
Axel
Still working on that. Being as the I/O card does not have a dedicated floppy drive controller, instead just the SMC COM2601 UART, the boot prom code appears to be controlling all aspects of the drives.
Making a guess, IN 05 is data in from the floppy drive, and I think OUT 16 is drive spindle motor on/off.
$7EBx locations in memory are stack.
Not sure what is at $8000 yet.
Phil
BOOT DISC ASSEMBLER MNEMONICS.txt
Here is the boot PROM contents, the jump/call points marked and partly annotated with comments.
Below is part of the first sector of the boot disc broken down as 8080 opcodes but I'm not certain of the structure (CRC values etc).
--Phil
There's definitely something of interest at locations $7EBx
I'm working through the boot PROM code, breaking it up and looking to see what it's doing. Obviously there's a number of memory location points that I need to go look up; mister-freeze pulled the ROM code from all the chips he could, so I shall have to investigate those.
I'll post up what I have once I've gone through it.
Phil
This very Heath-Robinson setup is being used to stress-test. With a basic logic test using jumper wires and LED's, the truth table of each chip is checked. Then, they are run at high frequency to see if they break down and fail at the speeds the computer uses.
Phil
I have decided to remove all logic, test and add a socket. Doing this means I can also capture a view of the electrical lines underneath each chip, which is difficult to do with the chips in place.
Slow but worth the effort, I think.
I shall attempt to create a schematic of the CPU board, at least.
Philip
Correction: One drive that works well. Two that do not.
I need to go look see if I have any spares. I do have a spare board and some other odds and ends. Punched another disc, and apart from the fact the media is no good, it is good with the timings to read and write. I took more care with this one to line up the index hole accurately, and punch the rest in accordance.
I'm also working on checking the board logic. I may see about writing a basic 8080 bootstrap and implanting that on the board to see if the logic is correct (without the I/O and VDU boards plugged in if that causes issues).
Phil
I tried to copy the System disc last night.
It compares exactly. I have one drive that works correctly. One does not and requires investigation.
Phil
Yes, 7/64". I knew there was a 7 in there somewhere.
My excuse: not feeling very well after having had my vaccination the other day.
Phil
Typography error! Please do correct me when I am wrong.
5/32" not 7/32"
I didn't have anything metric in stock, so that was the closest to 2,5mm that I had.
Nice Job!
We should merge the two solutions together!
The shape and the edges of your cutting tool look sharp as hell 👍
I may file it again so that the cutting edge is symmetrical, as office paper hole punches are.
That metal is very hard, it used to be a 7/32" (2,77mm) drill bit.
Philip
I had lengthened the times. I shall try add a bit more, the old Shugart spiral-drive stepper motors are slow and require quite a large impulse to move.
Either way, very positive results. I shall try match the other disc image when I finish work today.
Phil
Bad use of words on my part.
Write the 2F repeating pattern for 125kHz "blank", per Shugart?
I shall try that. We know your disk images are good; they booted and operated correctly.
the issue here will either be as you say, I'm reading different data because that's what was on the disc, or my drive isn't quite in calibration. I shall do as you say later on today, read the SYSTEM disc and compare.
Thanks
--Phil
[user = '50 '] mister-freeze [/ user] I took your dump files and did a stare-and-compare in Notepad. My read of your disc on the left, your .dmp file on the right.
It would appear that either the disc was meant to be empty or it is not formatting well or something because there's a moderate amount of data inconsistency. I used FLUXCOPY 0.90 test, compared to 0.3 Full you have on yours - perhaps that is the reason.
However, the dense areas of data are all immaculate and identical. Perhaps something in the way it is reading the disc?
Edit: Also not to discount that my disc drive may have bad hardware, also.
Edit 2: You wrote the disc with a 96tpi drive- my drive is probably not 100% aligned, and that's likely "noise" from data that was on the disc in the skipped tracks.
Maybe suggestion for PAW to have the track skip actually write the skipped tracks as zero flux instead of jumping over the track?
...and if it is not, FLUXCOPY will write, but not read the first sector.
Not a bad start but more care is required. I need a bigger wheel to turn the disk spindle with, I just marked the drive pulley with 16 lines.
Alles anzeigenpractically all 96 TPI CP / M drives (80 Track Double Density)
Most 48tpi drives also, single step (for floppy disks with 35 or 40 tracks).
In my experience, the 35/40 track floppy disks are written more reliably with a 48tpi volume.
The drives of the AES 103 are 48tpi / 35T.
With the 96 TPI drives with double step, the tracks are written "narrower".
Agreed. I have found that using an older drive to rewrite a disc has enough flux width to "plough the field", if you will accept the analogy.
Once it has been written with a 48tpi drive, often it can then be overwritten with a 96tpi drive successfully.
I discovered this when writing disc images using a PC, intended for use in my TRS-80/III.
Phil
