@oleg_mishin There really is no source code to share. As I wrote above, I hacked it in using DEBUG. But sure, I can try making an 808x compatible version of v5.55 as well.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
PC/XT-compatible-ish "AT" SCSI spotted
- Thread starter SomeGuy
- Start date
oleg_mishin
New Member
- Joined
- Nov 23, 2022
- Messages
- 5
Hi Oleg,
By coincidence, I have also made a SCSI adapter design based on the 53C80, mine contains a Zilog clone of this chip, the Z53C8003.
Simply because this chip is available to me at the moment, and it's a very basic chip which in my feeling seems to suit an XT PC.
I didn't have any card available for study/reference so I based my design on the Zilog SCSI chip datasheet.
I chose port 320 as the base port, and made jumpers for IRQ5/7, and DMA3.
I also added the /SCSI_EOP signal with a jumper to optionally connect it to the SCSI controller chip if I found it's supported.
This design is integrated on my Rev 2 XT mainboard and I have also made the design on a 8-bit adapter card with Realtek LAN, COM1 and boot ROM socket fixed at C800 as well. I am waiting for the 8-bit adapter PCBs which are delayed by DHL, so I can only test on the mainboard PCB for the moment.
So far I have done testing and debugging and my mainboard is working correctly. So I have now moved on to do some testing of the SCSI controller with various drivers and while searching I came across this thread.
My mainboard contains a V20 and I have tested the 5.55 bios, 6.3U-186.BIN as well. I simply included the 4k of these BIOS codes after enlarging them from 4k to 8k with empty space, then copied the BIOS with my other XT BIOS code and put the ROM in the F0000 space in the next available space block. My BIOS is like this:
8k blank - 8k blank - 8k blank - 8k blank - SCSI BIOS (8k) - HDFloppy22 - XT-IDE BIOS - PC-XT BIOS by Phatcode
What I found in my tests is that indeed the SCSI bios is loading, and it seems to attempt to write in the space which is after it's initial 4k, which is probably expected to be occupied by the 2k scratchpad RAM. Which of course corrupted my EEPROM.
So I proceeded to test with a normal EPROM which prevents corruption, just to be able to test and see what this BIOS will do.
I didn't expect things to work of course, but I am getting the option ROM message, and it reports to be "SEARCHING ..."
I can see the HDD activity light come on briefly once which seems to indicate that some communication to the HDD happened.
But the BIOS doesn't get past the "SEARCHING ..." message.
I have tested with IRQ5 and with and without DMA channel 3 connected to the chip
Actually, I am not looking for an option to boot from a SCSI drive, I just want SCSI available for file transfers and backups of my XT PC, and I use XT-IDE integrated for booting the XT itself. Since I am using a combined BIOS in the F0000 segment space, trying to boot using a SCSI BIOS will probably mess up the cooperation of the other BIOS images anyway on my configuration, which is what I found with other 8-bit SCSI cards so I used those without a BIOS with a driver only.
In my testing efforts on the 53C80 clone chip, I can report that the Mediavision PAS16 integrated SCSI driver which I found in the SCSI! bundle has the most response so far.
The options I used are:
DEVICE=C:\TSCSI\ASPIMED.SYS /P0320,05 /RW
Which selects port 320, IRQ5 and resets the SCSI chip, then sets a short wait period of a few seconds.
When I don't attach a drive, this aspi driver loads into memory successfully, reports the card to be present and I can use SCSITEST.EXE which finds the ASPI driver and adapter correctly.
When I attach a harddisk however, the driver doesn't complete loading, it stops at the polling phase of the driver load.
When I try to power up a harddisk, and use SCSITEST.EXE to poll the harddisk, it's not completing the detection properly either.
A SCSI CDROM seems to time out on detection/polling and then "no devices connected" is reported.
I believe I connected the SCSI bus correctly which seems pretty straightforward and I did apply termination on the adapter and at the drive, termination diode and fuse etc as usual.
I also tried with and without the parity bit option enabled on the drive but got the same results of not completing the device polling phase.
For reference, you can see some info on my project here:
I need to update this page soon since the prototype mainboard is currenly fully working and replaced revision 1 in the ATX case now.
Except for the SCSI of course.
I know I am taking a chance and skipped a few steps in my process, but I expected to need to revise the prototype PCB anyway and simply wanted to see if any current drivers would support this SCSI chip directly.
My goal is to have full integration and only needing to add a video card and a soundcard to complete the XT system.
As you can see on my web page, I did manage to get a simple 53C400 card(memory mapped connection) working fine already, and I have tested a Future Domain TMC-950 based card as well, though those drivers are not optimal on an XT and take rather long to load.
I just want to include SCSI because it's ideal for swapping an external harddisk for backup and file transfer purposes on an XT system.
I wanted to share my findings since I saw your post was recent and I am doing something relatively similar
I haven't completed all my testing yet, so I am still searching for more existing drivers and testing everything I can find.
I could opt to make a 4k ROM/2k RAM design as well to more closely match the card in this thread, but I am not there yet to have chosen to go this path, and still hoping to get the current design to work. I just want something very basic that is sufficient to use a SCSI harddisk externally and perhaps an internal SCSI CDROM as well. I am not too focused on high performance since the 8-bit bus speed is limited anyway.
I may also go the route to switch to a 53C400 chip design which I know to be working already in my system.
But from the historical viewpoint I like the 53C80 more because it's more original since it was the first chip type developed by NCR and feels more straightforward to me than the 53C400. I just want to gain an "essential" SCSI function with as little as possible components. I had some free space on the mainboard which suited this kind of design exactly.
I still hope I can get this very basic chip to function, and would appreciate any tips or ideas.
Of course if I get it to work, I will share the findings here as well
Kind regards,
Rodney
Attachments
Wow, this is a really interesting integration project, @rodney . I’m reading through your project notes, and will be interested to see how it comes along.
Are you going to make your boards available for sale, or will you publish them for others to order, and learn from? Either would be great, if you are so inclined.
- Alex
Are you going to make your boards available for sale, or will you publish them for others to order, and learn from? Either would be great, if you are so inclined.
- Alex
Hi Alex,
Thanks for your message, your interest is appreciated. This XT project has shown me that the XT PC is somewhat complicated for example compared to Z80 systems. IBM set the standard but I feel it's also largely defined and elaborated by clone manufacturers which is sometimes perhaps underrated. Those clone manufacturers contributed greatly to advance the popularity of PCs. I feel both are equally important to advancing the industry standard PC. What attracted me to the XT is its 8-bit "simplicity", and the fact that modern PCs are evolved from it. I have worked in IT and my earliest experiences were AT 286 PCs and upward from those.
When I developed this design I studied the IBM PC and also clone schematics in depth. I made my own circuits for various functions of the XT system. I must say that I have grown to like clone computers a bit more because they are usually a little more advanced already compared to the original IBM PC. Also, the BIOS of clone PCs is usually more versatile and supports more equipment, it's simply more useful and compatible with expansions.
There are various 8088 designs on the internet such as Sergey's XT for example. I like his designs too, he did some things differently from my design which is also fine and functional. I think all these XTs should function sufficiently, though things may get more complex when creating a more elaborate PC system. That's when you may experience some issues, which however are quite solvable once found and understood. Though I can understand that some builders would be discouraged by this experience. Some people just want to solder together something, however in this case it's not a matter of merely assembling the PCB, but also of understanding various issues which may occur when you use it to assemble a complete system. There is of course a bit more difficulty, but also the opportunity to gain more experience in understanding system problems. Most of those issues are quite common have been documented by designers and some may be a little quirky to deal with. Those are the worst though! Check out my updated project page if you like, there you can find some of those quirks which I described on that page today. I did decide to fully support the "X" bus as made by IBM on all my XT designs because in supporting this method, it will also distribute the internal and external bus load more which benefits more complete systems. And remember, these days things are also a lot less complicated because we can use SRAM, and we are no longer plagued by the tricky timings of DRAM chips which are the subject of influence by chip impedance, PCB trace impedance, quirky manufacturers etc. At least we don't have that, and let's not forget the substantial reduction in required PCB space and component count on a mainboard. Definately, the design could be done differently, for example on my CP/M Z80 mainboard I had no example of an existing complete system so I had to design my own kind of buffering to provide for a logic chip load distribution on the various buses. So there I created a memory bus, I/O bus and expansion bus separately. The tricky point is of course the data tranceiver control and switching and making sure that there is no bus contention able to happpen anywhere. Sometimes it's better to design from the ground up, but in the case of the XT, it's recreating the historical system which I also want to respect and don't want to stray off from the standard so much that it won't be compatible anymore either.
Mostly when you buy a clone mainboard, it has been tested well by the manufacturer with the common expansion cards of that time period, so surely they already saw the quirks and applied some small fixes to prevent them. Often a fix will be very simple since the cause is mostly a small matter. The problem is to discover what the small matter is of course! When making your own mainboard, it's up to the builder to discover the problems and fix them. I must say, after fixing what I found, I did have a very nice PC experience of plugging in adapter cards and getting them to work in a normal fashion like we would have back in those days. That was really my intention to do this. I never owned or saw an actual XT system before building one. I bought a cheap SCSI card by Alea Systems which turned out to be a Future Domain card, apparently an early Adaptec design, someone had stripped out the loose ICs, but I could see one of them is a LS245 transceiver and the other a simple boot ROM. So I quickly got this SCSI card to work. Then while testing it I discovered that SCSI really is as useful as USB in the case of an XT and early AT PCs. It's really much more pluggable and versatile than for example IDE and such. I still should do more performance testing with a SCSI harddisk in DOS and Windows 3.0, which should perform better than IDE due to the command structure of SCSI. I could opt to boot from XT-IDE and then load the remaining DOS drivers and windows from an internal SCSI disk, though that's for later if and when I get this SCSI chip to work with a usable driver.
My mainboard works really well, though the power on circuit is sometimes a bit quirky if in powered down state the VCC voltage remains raised slightly by some external powered device connected to the XT system. This prevents a reset of one of the logic chips to occur, even if it's only 0,5V or something very low. I applied a few fixes to cancel this problem and mostly now it's not happening anymore, unless there is a powerful raise of voltage on an external connection. Designing logic chips from a transistor and diode viewpoint is a complicated matter, and when connecting powered ICs with ICs which are powered off at certain moments, you may get quirky results. Which happens when you need some circuits that remain on standby for example to sense a power button of course. I don't like using microcontrollers or other custom chips for ATX power supply control though, and really prefer my quirky solution which may seem a little unusual but for me it works comfortably. Anyway, to me this is a hobby project with in the background also a motive to learn and develop more design skills and experience as a bonus.
Thanks for your message, your interest is appreciated. This XT project has shown me that the XT PC is somewhat complicated for example compared to Z80 systems. IBM set the standard but I feel it's also largely defined and elaborated by clone manufacturers which is sometimes perhaps underrated. Those clone manufacturers contributed greatly to advance the popularity of PCs. I feel both are equally important to advancing the industry standard PC. What attracted me to the XT is its 8-bit "simplicity", and the fact that modern PCs are evolved from it. I have worked in IT and my earliest experiences were AT 286 PCs and upward from those.
When I developed this design I studied the IBM PC and also clone schematics in depth. I made my own circuits for various functions of the XT system. I must say that I have grown to like clone computers a bit more because they are usually a little more advanced already compared to the original IBM PC. Also, the BIOS of clone PCs is usually more versatile and supports more equipment, it's simply more useful and compatible with expansions.
There are various 8088 designs on the internet such as Sergey's XT for example. I like his designs too, he did some things differently from my design which is also fine and functional. I think all these XTs should function sufficiently, though things may get more complex when creating a more elaborate PC system. That's when you may experience some issues, which however are quite solvable once found and understood. Though I can understand that some builders would be discouraged by this experience. Some people just want to solder together something, however in this case it's not a matter of merely assembling the PCB, but also of understanding various issues which may occur when you use it to assemble a complete system. There is of course a bit more difficulty, but also the opportunity to gain more experience in understanding system problems. Most of those issues are quite common have been documented by designers and some may be a little quirky to deal with. Those are the worst though! Check out my updated project page if you like, there you can find some of those quirks which I described on that page today. I did decide to fully support the "X" bus as made by IBM on all my XT designs because in supporting this method, it will also distribute the internal and external bus load more which benefits more complete systems. And remember, these days things are also a lot less complicated because we can use SRAM, and we are no longer plagued by the tricky timings of DRAM chips which are the subject of influence by chip impedance, PCB trace impedance, quirky manufacturers etc. At least we don't have that, and let's not forget the substantial reduction in required PCB space and component count on a mainboard. Definately, the design could be done differently, for example on my CP/M Z80 mainboard I had no example of an existing complete system so I had to design my own kind of buffering to provide for a logic chip load distribution on the various buses. So there I created a memory bus, I/O bus and expansion bus separately. The tricky point is of course the data tranceiver control and switching and making sure that there is no bus contention able to happpen anywhere. Sometimes it's better to design from the ground up, but in the case of the XT, it's recreating the historical system which I also want to respect and don't want to stray off from the standard so much that it won't be compatible anymore either.
Mostly when you buy a clone mainboard, it has been tested well by the manufacturer with the common expansion cards of that time period, so surely they already saw the quirks and applied some small fixes to prevent them. Often a fix will be very simple since the cause is mostly a small matter. The problem is to discover what the small matter is of course! When making your own mainboard, it's up to the builder to discover the problems and fix them. I must say, after fixing what I found, I did have a very nice PC experience of plugging in adapter cards and getting them to work in a normal fashion like we would have back in those days. That was really my intention to do this. I never owned or saw an actual XT system before building one. I bought a cheap SCSI card by Alea Systems which turned out to be a Future Domain card, apparently an early Adaptec design, someone had stripped out the loose ICs, but I could see one of them is a LS245 transceiver and the other a simple boot ROM. So I quickly got this SCSI card to work. Then while testing it I discovered that SCSI really is as useful as USB in the case of an XT and early AT PCs. It's really much more pluggable and versatile than for example IDE and such. I still should do more performance testing with a SCSI harddisk in DOS and Windows 3.0, which should perform better than IDE due to the command structure of SCSI. I could opt to boot from XT-IDE and then load the remaining DOS drivers and windows from an internal SCSI disk, though that's for later if and when I get this SCSI chip to work with a usable driver.
My mainboard works really well, though the power on circuit is sometimes a bit quirky if in powered down state the VCC voltage remains raised slightly by some external powered device connected to the XT system. This prevents a reset of one of the logic chips to occur, even if it's only 0,5V or something very low. I applied a few fixes to cancel this problem and mostly now it's not happening anymore, unless there is a powerful raise of voltage on an external connection. Designing logic chips from a transistor and diode viewpoint is a complicated matter, and when connecting powered ICs with ICs which are powered off at certain moments, you may get quirky results. Which happens when you need some circuits that remain on standby for example to sense a power button of course. I don't like using microcontrollers or other custom chips for ATX power supply control though, and really prefer my quirky solution which may seem a little unusual but for me it works comfortably. Anyway, to me this is a hobby project with in the background also a motive to learn and develop more design skills and experience as a bonus.
I like to help people when I can, if there is no trouble arising from it. About selling PCBs, that's not really my plan though. I may be persuaded to mail out a few bare PCBs to enthousiastic builders very similar to myself, of course under the express condition not to resell the system based on it on ebay etc, and not to use it for any commercial or critical application. This is a hobby project, nothing serious. And the builder is required to be able to troubleshoot by him or herself and not blaming me for it if they can't get it to work and they can't locate the cause due to lack of skill or patience. There is always a small risk of accidentally leaving a solder bridge which is hard to spot, or getting a flake or speck of solder underneath a socket, etc. That kind of issue may take a long time and patience to discover. I am willing to give some advice, however no guarantees and no promises will be given and the builder needs to take their own responsibility, not expect me to solve their problems, I just don't have the time or opportunity for that in my life. I just want to be clear on it. I am not planning to distribute the designs either because I feel it will invite commercialization. I once published a schematic and some guy in Brazil abused it to sell his own version of my design for a profit, hurting the guy who kindly helped me to integrate some of his own circuits into my design. The Brazilian individual even lied to that kind guy claiming that he got the programming code from my website, which he didn't, I was already careful never to publish that. Some people are not honest and want to shift blame to others which already happened to me. I don't want to hurt any PCB sellers by helping other people to compete with their business, or do anything else that might be seen as unfair. And I don't want to compete with people who are already selling XT mainboards commercially. Some people really may need the money which I respect and I don't want anything to happen. I am not well off myself, on the contrary, but I don't plan to make this my income either, it will remain a hobby and strictly for educational purposes for me. Anything that comes from me is strictly meant for this purpose only. I needed to elaborate on this which is boring to read but I have learned some lessons from experience that things need to be clear.
So if anyone with enough experience and expertise who agrees the above conditions would like to have a PCB, let me know about it. I will note it and see what I can do, and get in touch if I have the chance and feel so inclined. I am quite busy at the moment in my life, a lot of stuff going on in my life, and I have children that go to school, so my time and energy will be limited and varied somewhat. And my priority will be the projects themselves. Regarding the costs, I will simply want a compensation of fabrication and shipping. It's only fair and not that much, thanks to JLCPCB in Chna. I have already drafted a component list of which logic types need to go into which IC locations to have the best chance of achieving valid I/O timing on the system. I have found some variation between brands so I can advise on this a little to reply which brands I used for what. On my second build of this revision 2, where I soldered everything directly to the PCB, I used mostly ICs which I harvested from useless old PCBs, I was cleaning out my old PCBs and stripping the DIP ICs off with an SMD hot air soldering iron. For example some useless old 1980s POS computer of some weird custom design which is not any standard, it contained so many logic chips which I can use so I stripped it bare. Once you get the technique and timing right, it is much easier and faster than using a desoldering iron.
I do plan a third revision mainboard after I have determined if the SCSI chip is able to function with some existing drivers. I just need a few very small changes such as I want to make the SMD pads of the SCSI chip stick out a little bit more outside the chip. That makes hand soldering a lot easier since it's more easy to heat the PCB pad and let the solder flow onto it. This time on the second PCB I soldered, I first tinned all SMD pads of the SCSI chip with a thin flat layer of solder, and then positioned the SCSI chip and hot air heated the pads to fasten it onto the PCB. When the pins and pads are already thermally connected, it's much more easy to solder reliably with some 0,35 mm solder wire and a needle shaped soldering tip such as LT-1S. And adding a resistor network to the PCB rather than soldering it to the bottom, updating a few capacitor silkscreen value texts, that kind of small things I may edit the PCB and perhaps make a revision 3 board.
Anyway, to get back onto the subject of this thread, if anyone knows of some basic simple SCSI drivers which support the 53C80 as it was initially and originally designed to function by NCR, as somewhat described in their datasheets, please let me know about it. When I can get the SCSI chip to function with an ASPI driver, I will also share my findings here of course.
So if anyone with enough experience and expertise who agrees the above conditions would like to have a PCB, let me know about it. I will note it and see what I can do, and get in touch if I have the chance and feel so inclined. I am quite busy at the moment in my life, a lot of stuff going on in my life, and I have children that go to school, so my time and energy will be limited and varied somewhat. And my priority will be the projects themselves. Regarding the costs, I will simply want a compensation of fabrication and shipping. It's only fair and not that much, thanks to JLCPCB in Chna. I have already drafted a component list of which logic types need to go into which IC locations to have the best chance of achieving valid I/O timing on the system. I have found some variation between brands so I can advise on this a little to reply which brands I used for what. On my second build of this revision 2, where I soldered everything directly to the PCB, I used mostly ICs which I harvested from useless old PCBs, I was cleaning out my old PCBs and stripping the DIP ICs off with an SMD hot air soldering iron. For example some useless old 1980s POS computer of some weird custom design which is not any standard, it contained so many logic chips which I can use so I stripped it bare. Once you get the technique and timing right, it is much easier and faster than using a desoldering iron.
I do plan a third revision mainboard after I have determined if the SCSI chip is able to function with some existing drivers. I just need a few very small changes such as I want to make the SMD pads of the SCSI chip stick out a little bit more outside the chip. That makes hand soldering a lot easier since it's more easy to heat the PCB pad and let the solder flow onto it. This time on the second PCB I soldered, I first tinned all SMD pads of the SCSI chip with a thin flat layer of solder, and then positioned the SCSI chip and hot air heated the pads to fasten it onto the PCB. When the pins and pads are already thermally connected, it's much more easy to solder reliably with some 0,35 mm solder wire and a needle shaped soldering tip such as LT-1S. And adding a resistor network to the PCB rather than soldering it to the bottom, updating a few capacitor silkscreen value texts, that kind of small things I may edit the PCB and perhaps make a revision 3 board.
Anyway, to get back onto the subject of this thread, if anyone knows of some basic simple SCSI drivers which support the 53C80 as it was initially and originally designed to function by NCR, as somewhat described in their datasheets, please let me know about it. When I can get the SCSI chip to function with an ASPI driver, I will also share my findings here of course.
oleg_mishin
New Member
- Joined
- Nov 23, 2022
- Messages
- 5
Hi @rodney, Thank you very much for sharing your project and your experience. It is really impressive.
In my project, as I very limited in time(almost the same situation as yours: family, kids etc
), I targeted to clone an existing board which I bought on ebay. So I can use the board as a starting point. When the hardware done move to digging in its BIOS. It would be very interesting if the scratchpad RAM can be moved to other location or removed completely. But the last time I used assembler was more than 20 years ago
Anyway, the board I shared on Github, based on also Zilog SCSI IC, works well. I fixed a small mistake there and it now I can boot from it on AT computer and on XT with VC20 CPU. I have not yet tested the drivers as the board is bootable which is enough for me so far. Will check later.
The main issue with 53C80 board is that it doesn't start with the latest 6.3 BIOS(hings at "Searching ..."). With 5.55 - no problem with AT at least.
Actually, I made another SCSI card based on 53C400(A). A clone of Trantor T130B. The prototype works well and it is bootable on any PC (XT, AT and 386). I expect a fixed boards from Jlcpcb soon and if it is ok will release files on Github. Had no problem using SCSI hard drives and CD-ROM. Btw, I have not find any difference using 53C400A and without "A". Both work ok.
In my project, as I very limited in time(almost the same situation as yours: family, kids etc
), I targeted to clone an existing board which I bought on ebay. So I can use the board as a starting point. When the hardware done move to digging in its BIOS. It would be very interesting if the scratchpad RAM can be moved to other location or removed completely. But the last time I used assembler was more than 20 years ago Anyway, the board I shared on Github, based on also Zilog SCSI IC, works well. I fixed a small mistake there and it now I can boot from it on AT computer and on XT with VC20 CPU. I have not yet tested the drivers as the board is bootable which is enough for me so far. Will check later.
The main issue with 53C80 board is that it doesn't start with the latest 6.3 BIOS(hings at "Searching ..."). With 5.55 - no problem with AT at least.
Actually, I made another SCSI card based on 53C400(A). A clone of Trantor T130B. The prototype works well and it is bootable on any PC (XT, AT and 386). I expect a fixed boards from Jlcpcb soon and if it is ok will release files on Github. Had no problem using SCSI hard drives and CD-ROM. Btw, I have not find any difference using 53C400A and without "A". Both work ok.
Hi @oleg_mishin, nice to see your reply, it's great to talk with someone who is doing some design and build work too, and interesting and useful to read about your findings and other work.
I was also thinking about this scratchpad issue. If it turns out I need some scratchpad memory, I could map it into the SRAM chip on a future mainboard if the driver really requires it. It's not so desirable to have a scratchpad on the SCSI solution because the scratchpad RAM is always very tiny which requires more gates to decode only that segment of memory. It seems a little silly to map some RAM with the card and decode that while there are huge amounts of RAM in the system itself, directly available for the CPU and DMA controller. Maybe they had some reason I didn't realise yet but it seems a little useless.
I really like the Zilog SCSI solution best because it would enable us to build new SCSI cards and integrated SCSI solution.
I really want to first definatively conclude whether the 53C80 can be supported in a basic XT configuration with existing drivers, preferably supporting direct DMA as well. This is one of the best features of SCSI of course and would make the solution a lot faster and less CPU intensive which is what suits the XT PC more. I will do some more searching for drivers and test any I can find.
Today I received the adapter cards from JLCPCB which contains the Zilog SCSI interface too. This will also enable me to test with the Nolan Computer Supplies NCS-250-SC Windows 95 SCSI drivers in a pentium PC when I have the chance. From this I could at least conclude that the interface and timing are both functional if I can't determine this otherwise with existing drivers. The hardest thing will be getting this chip to work on an XT, since more drivers are more likely to work on 286 and upwards, which was also my experience when testing my 53C400 card. Indeed it seems to be mostly identical to the 53C400A, that is also what I assumed.
About assembler, I am sure you have done more than me already since I never have programmed assembler on a PC I only did some simple machine coding on a Z80 in my school years which was also long ago.
I will write some results here and on my website as soon as I am further in my testing work to reach a conclusion about the Zilog chip.
In the mean time, if anyone reads this thread and has some adapter card featuring a 53C80 chip or any clone of it, or knows about one, and knows of some ASPI drivers which support a direct interface with this chip, please let us know and post a message here. That would be very helpful for anyone with similar interests who finds this thread in the future as well.
Otherwise I will have to choose one of two paths, either more elaborately match an existing 53C80 adapter card with drivers already known to work on an XT, or just choose the 53C400 and accept the limited availability of it. At least that one works well with the LS2000 ASPI driver which I verified. For me, I really don't like solutions with boot code integrated because it messes up my BIOS interaction between different segments of my XT BIOS. Those SCSI ROM codes are too old to properly interact with XT-IDE and HD floppy code for XT. So if the ASPI driver requires the BIOS to be present, that card is really not suitable in my XT system. So then I may go with the 53C400 after all. It doesn't need anything else except some passive components and a bus transceiver, BIOS is purely optional for those who want one.
I was also thinking about this scratchpad issue. If it turns out I need some scratchpad memory, I could map it into the SRAM chip on a future mainboard if the driver really requires it. It's not so desirable to have a scratchpad on the SCSI solution because the scratchpad RAM is always very tiny which requires more gates to decode only that segment of memory. It seems a little silly to map some RAM with the card and decode that while there are huge amounts of RAM in the system itself, directly available for the CPU and DMA controller. Maybe they had some reason I didn't realise yet but it seems a little useless.
I really like the Zilog SCSI solution best because it would enable us to build new SCSI cards and integrated SCSI solution.
I really want to first definatively conclude whether the 53C80 can be supported in a basic XT configuration with existing drivers, preferably supporting direct DMA as well. This is one of the best features of SCSI of course and would make the solution a lot faster and less CPU intensive which is what suits the XT PC more. I will do some more searching for drivers and test any I can find.
Today I received the adapter cards from JLCPCB which contains the Zilog SCSI interface too. This will also enable me to test with the Nolan Computer Supplies NCS-250-SC Windows 95 SCSI drivers in a pentium PC when I have the chance. From this I could at least conclude that the interface and timing are both functional if I can't determine this otherwise with existing drivers. The hardest thing will be getting this chip to work on an XT, since more drivers are more likely to work on 286 and upwards, which was also my experience when testing my 53C400 card. Indeed it seems to be mostly identical to the 53C400A, that is also what I assumed.
About assembler, I am sure you have done more than me already since I never have programmed assembler on a PC
I only did some simple machine coding on a Z80 in my school years which was also long ago.I will write some results here and on my website as soon as I am further in my testing work to reach a conclusion about the Zilog chip.
In the mean time, if anyone reads this thread and has some adapter card featuring a 53C80 chip or any clone of it, or knows about one, and knows of some ASPI drivers which support a direct interface with this chip, please let us know and post a message here. That would be very helpful for anyone with similar interests who finds this thread in the future as well.
Otherwise I will have to choose one of two paths, either more elaborately match an existing 53C80 adapter card with drivers already known to work on an XT, or just choose the 53C400 and accept the limited availability of it. At least that one works well with the LS2000 ASPI driver which I verified. For me, I really don't like solutions with boot code integrated because it messes up my BIOS interaction between different segments of my XT BIOS. Those SCSI ROM codes are too old to properly interact with XT-IDE and HD floppy code for XT. So if the ASPI driver requires the BIOS to be present, that card is really not suitable in my XT system. So then I may go with the 53C400 after all. It doesn't need anything else except some passive components and a bus transceiver, BIOS is purely optional for those who want one.
Hello everyone,
A small update, I have been searching extensively and testing loads of DOS ASPI drivers on my XT PC with the Zilog 53C80 SCSI clone chip, it's really a simple configuration, IO Port 320, IRQ 5, DMA is optional.
However I could not find any other driver except the Media Vision Pro audio SCSI ASPI driver which is the only ASPI driver I could find seems to have a similar configuration to my circuits. If I ever come across one of these soundcards I may try to buy it for testing to see what's exactly different on these cards compared to my design. It must be a subtle difference like an extra transceiver somewhere which is missing on my circuits. Instinctively I am suspecting this to be the case here. I have been studying photos of these cards but could not definatively find any indication what the issue might be.
I am close to giving up and switching to the 53C400 chip. This chip I already have a simple card and working drivers for, which I at least already was able to test with SCSI harddisks and CDROM drives.
I didn't have time yet to build an adapter card version of the Zilog 53C80 SCSI clone chip, I haven't spent time on it yet because I already know I won't have a DOS driver for it anyway. So at most it might be useful for a Windows 95 PC, however that's not my main goal at this moment.
So I will probably be focussing my time on the 53C400 and making a revision 3 mainboard which includes that soon, at least I will have the guarantee that this is going to have driver support.
I did read somewhere about some source code which was distributed by NCR to chip clients for the 53C80 and 53C400 which could be compiled into a boot ROM image. However this is apparently primitive code which needs to be edited for each different configuration of harddisk, so it's not very useful either. Besides, I am not looking for ROM code but rather an ASPI DOS driver.
Kind regards,
Rodney
A small update, I have been searching extensively and testing loads of DOS ASPI drivers on my XT PC with the Zilog 53C80 SCSI clone chip, it's really a simple configuration, IO Port 320, IRQ 5, DMA is optional.
However I could not find any other driver except the Media Vision Pro audio SCSI ASPI driver which is the only ASPI driver I could find seems to have a similar configuration to my circuits. If I ever come across one of these soundcards I may try to buy it for testing to see what's exactly different on these cards compared to my design. It must be a subtle difference like an extra transceiver somewhere which is missing on my circuits. Instinctively I am suspecting this to be the case here. I have been studying photos of these cards but could not definatively find any indication what the issue might be.
I am close to giving up and switching to the 53C400 chip. This chip I already have a simple card and working drivers for, which I at least already was able to test with SCSI harddisks and CDROM drives.
I didn't have time yet to build an adapter card version of the Zilog 53C80 SCSI clone chip, I haven't spent time on it yet because I already know I won't have a DOS driver for it anyway. So at most it might be useful for a Windows 95 PC, however that's not my main goal at this moment.
So I will probably be focussing my time on the 53C400 and making a revision 3 mainboard which includes that soon, at least I will have the guarantee that this is going to have driver support.
I did read somewhere about some source code which was distributed by NCR to chip clients for the 53C80 and 53C400 which could be compiled into a boot ROM image. However this is apparently primitive code which needs to be edited for each different configuration of harddisk, so it's not very useful either. Besides, I am not looking for ROM code but rather an ASPI DOS driver.
Kind regards,
Rodney
Eudimorphodon
Veteran Member
Did you locate/try a copy of Trantor SCSIworks? The scsi on the PAS was similar to several other braindead/low end cards made by Trantor and Adaptec, and I remember that package being useful. Maybe the driver for the T128 or similar would be closer to what you need.
Thanks for your reply Eudimorphodon,
Yes, I have tried the Trantor drivers for the T128. I also tried a driver collection by Corel and a driver collection called "SCSI!".
Further I found other collections of driver files and searched for Chinon CDROM drivers because some Chinon models were bundled with the NCS card.
I also tried the NCR SDMS3 driver bundle and later Symbios logic drivers.
What I also did was to check the command line options of the drivers, especially Corel drivers do have these sometimes.
I also used DEVLOAD.COM to be able to more easily query the driver to respond to command line options.
For example some drivers respond to the /P0320,05 or /p320 option to select the I/O port.
I also hex edited the binary code to check any ASCII responses embedded in drivers to see if there are any clues to options etc.
I have searched for simple 53C80 cards and made a list of the brands and models I found.
These are some of the cards I found:
Advanced Storage Concepts ASC-88
GS-II
Everex EV-8114
Emerald 10081 (WDC version chip)
Nolan Computer Systems NCS-250-SC
Sumo Systems / Storage Plus Inc SCSI-AT
Trantor T128
Rodime SCSI card
Media Vision pro sound cards with SCSI
Longshine driver archive in Germany
Of these I only found the ASPI drivers for the SCSI-AT, Trantor T128, Media Vision cards and Longshine cards which I have tested.
There are many variations of designs, both I/O mapped and memory mapped, with and without BIOS.
I will do some last testing today, maybe I overlooked something while testing the Media Vision drivers which so far seem to be most promising.
I just read the NCR documentation on the 53C80 once again, and I may have found where the problem is.
There may indeed be a small piece of the SCSI adapter circuits missing.
Previously I believed that the host adapter SCSI ID was set automatically to ID 7 internally by the 53C80, however I now believe that's not the case.
I saw a small reference design using a 65C02 CPU where NCR used a LS244 buffer to read a set of jumper inputs onto the CPU databus.
This buffer activates on the IO decoder of the SCSI I/O address with the addition of the A3 address line.
When A3=1 and A2=0 in the reference circuit, an IO Read will result in the jumper values being put onto the CPU databus.
This may be the same mechanism which the Media Vision ASPI driver is looking for.
I will build a small PCB to add this jumper block to the adapter circuits to check if this could result in correct SCSI polling using this ASPI driver with the correct ID setting on that IO port.
The driver seems to poll ID 6 to find the host adapter itself, so I may need to set this ID on the added circuit.
The reference circuit and datasheet of NCR don't go into any details about the host adapter SCSI ID, so I guess this must be defined by the manufacturer in their ASPI driver.
Maybe some manufacturers assume host SCSI ID is always 7 in the driver itself for simplicity of design.
I am not sure if I am on the right track here, but I will try this when I can and post back here.
If this turns out not to be the problem I will probably quit working on this SCSI chip.
There may indeed be a small piece of the SCSI adapter circuits missing.
Previously I believed that the host adapter SCSI ID was set automatically to ID 7 internally by the 53C80, however I now believe that's not the case.
I saw a small reference design using a 65C02 CPU where NCR used a LS244 buffer to read a set of jumper inputs onto the CPU databus.
This buffer activates on the IO decoder of the SCSI I/O address with the addition of the A3 address line.
When A3=1 and A2=0 in the reference circuit, an IO Read will result in the jumper values being put onto the CPU databus.
This may be the same mechanism which the Media Vision ASPI driver is looking for.
I will build a small PCB to add this jumper block to the adapter circuits to check if this could result in correct SCSI polling using this ASPI driver with the correct ID setting on that IO port.
The driver seems to poll ID 6 to find the host adapter itself, so I may need to set this ID on the added circuit.
The reference circuit and datasheet of NCR don't go into any details about the host adapter SCSI ID, so I guess this must be defined by the manufacturer in their ASPI driver.
Maybe some manufacturers assume host SCSI ID is always 7 in the driver itself for simplicity of design.
I am not sure if I am on the right track here, but I will try this when I can and post back here.
If this turns out not to be the problem I will probably quit working on this SCSI chip.
oleg_mishin
New Member
- Joined
- Nov 23, 2022
- Messages
- 5
Hi @rodney,
Thank you for posting your findings.
As there are many cards built on 5380 and almost all of them have here or there some circuit difference. I think it is not possible to use drivers from other cards on the same chip.
Finally I decided to get T128 in my hands and clone it. Seems only this card has bootable BIOS and good set of drivers.
I will keep community updated.
Regards
Oleg
Thank you for posting your findings.
As there are many cards built on 5380 and almost all of them have here or there some circuit difference. I think it is not possible to use drivers from other cards on the same chip.
Finally I decided to get T128 in my hands and clone it. Seems only this card has bootable BIOS and good set of drivers.
I will keep community updated.
Regards
Oleg
Hi @oleg_mishin
Thanks for your response. Definately, having a card on hand would be a big advantage to be able to determine how the manufacturer made the circuits and drivers interact. And it's possible to use a scope on the signals to see what is used for which purpose etc. I totally understand your project motivations and it's really useful, I am definately interested and will watch your posts and your project.
I was just thinking the same thing when I read your message here. When I looked at all the different 53C80 cards I noticed many circuit differences, I even made a list to note these. There are more simple cards and more complex ones around. For example the Media Vision where SCSI was simply a feature, similar to my purpose that I was looking for. I had hoped to at least find a similar simple SCSI card and use those drivers. If I had more time I would try to get more of these cards and look into the matter in more depth. However I want to keep on my purpose which is adding a SCSI interface to my mainboard and adapter card designs.
I am seeing that the SCSI bus is correctly polled as the SS.EXE utility pauses at exactly the ID of the SCSI device I connected for testing, and skips the ID when that device is powered off.
I tested the reference circuit for setting the host bus adapter ID with an additional I/O port as seen in the NCR datasheet however with that Media Vision driver it's not reading the expected I/O port, so it's not looking at that.
So that's not the solution, there is something else not matching what the driver expects. Whatever it is, I didn't spot it on the soundcard just from the photos.
Since I don't have any example cards similarly simple as the circuits I want to use, I will be switching to the 53C400 chip for my projects. I have that card here, fully tested it, and after checking I found it closely matches the more detailed reference schematic by NCR. The chip is larger in size, so I will find a way to make space for it and I will be making another mainboard to use the 53C400 instead. At least I like this driver, it's very fast on an XT. This whole experience was great and even though I have not been successful to get the Zilog chip going, I don't mind it, I still learned more about SCSI adapters in the process and I will keep this design in mind in case I am able to buy an existing card for testing in the future. The 53C80 project is on pause for now so I can proceed with my mainboard development.(and have more time available for this later) I am more looking for simplicity myself, but I also like your project very much because to be able to boot a system from SCSI is also very nice. I may also build one in the future.
I will be watching your progress, I will start a new thread when I have the new mainboard made and tested.
Thanks for your response. Definately, having a card on hand would be a big advantage to be able to determine how the manufacturer made the circuits and drivers interact. And it's possible to use a scope on the signals to see what is used for which purpose etc. I totally understand your project motivations and it's really useful, I am definately interested and will watch your posts and your project.
I was just thinking the same thing when I read your message here. When I looked at all the different 53C80 cards I noticed many circuit differences, I even made a list to note these. There are more simple cards and more complex ones around. For example the Media Vision where SCSI was simply a feature, similar to my purpose that I was looking for. I had hoped to at least find a similar simple SCSI card and use those drivers. If I had more time I would try to get more of these cards and look into the matter in more depth. However I want to keep on my purpose which is adding a SCSI interface to my mainboard and adapter card designs.
I am seeing that the SCSI bus is correctly polled as the SS.EXE utility pauses at exactly the ID of the SCSI device I connected for testing, and skips the ID when that device is powered off.
I tested the reference circuit for setting the host bus adapter ID with an additional I/O port as seen in the NCR datasheet however with that Media Vision driver it's not reading the expected I/O port, so it's not looking at that.
So that's not the solution, there is something else not matching what the driver expects. Whatever it is, I didn't spot it on the soundcard just from the photos.
Since I don't have any example cards similarly simple as the circuits I want to use, I will be switching to the 53C400 chip for my projects. I have that card here, fully tested it, and after checking I found it closely matches the more detailed reference schematic by NCR. The chip is larger in size, so I will find a way to make space for it and I will be making another mainboard to use the 53C400 instead. At least I like this driver, it's very fast on an XT. This whole experience was great and even though I have not been successful to get the Zilog chip going, I don't mind it, I still learned more about SCSI adapters in the process and I will keep this design in mind in case I am able to buy an existing card for testing in the future. The 53C80 project is on pause for now so I can proceed with my mainboard development.(and have more time available for this later) I am more looking for simplicity myself, but I also like your project very much because to be able to boot a system from SCSI is also very nice. I may also build one in the future.
I will be watching your progress, I will start a new thread when I have the new mainboard made and tested.
oleg_mishin
New Member
- Joined
- Nov 23, 2022
- Messages
- 5
Hello @rodney,
I'd like to share an update on my 5380 card. I got a T-128 in my hands and was able to make a circuit diagram of it.
Two PAL's were reverse engineered as well. The registered one was a bit tough
I positively tested the following and find the card quite well matching kind of requirements to be used in XT/AT systems:
- Bootable in XT with 8088 CPU.
- ASPI drivers for DOS. Tested with ZuluSCSI CD-ROM.
- Works with BlueSCSI/ZuluSCSI
Please find all the the info in "Reference" folder of my project:
github.com
I hope it is enough for you to make a decision whether to continue or not with 5380.
Most likely I will go with a CPLD design to replace all those logic parts and have the card to be reconfigured easily.
I'd like to share an update on my 5380 card. I got a T-128 in my hands and was able to make a circuit diagram of it.
Two PAL's were reverse engineered as well. The registered one was a bit tough
I positively tested the following and find the card quite well matching kind of requirements to be used in XT/AT systems:
- Bootable in XT with 8088 CPU.
- ASPI drivers for DOS. Tested with ZuluSCSI CD-ROM.
- Works with BlueSCSI/ZuluSCSI
Please find all the the info in "Reference" folder of my project:
GitHub - OlegMishin/OLM-T128: ISA SCSI host adapter (Trantor T128 clone)
ISA SCSI host adapter (Trantor T128 clone). Contribute to OlegMishin/OLM-T128 development by creating an account on GitHub.
github.com
Most likely I will go with a CPLD design to replace all those logic parts and have the card to be reconfigured easily.
Hi Oleg,
It's nice to see your update.
My compliments on your work!
You are preserving a piece of historical technology.
I just want to say, I see your work and I also feel that it is a valuable effort.
I am also doing my work for preservation of historical designs even though I may have changed them already.
Not many people may understand this point, depending on how they feel about it.
Otherwise many designs will get lost in time never to be found again for sure.
This already happened too much.
I always feel surprised that someone would not feel it's important to preserve these designs, especially the people who originally made them.
I would not want my work to disappear and would always make sure to keep it somewhere in some form at least.
Finally I decided to abandon the idea of using the 5380 on the mainboard.
I mean, if I were determined, I could integrate your schematics into my mainboard,
however it would take up a lot of PCB space which made me decide against it.
On a card it would be fine to use your Trantor schematics of course.
That area of my mainboard is quite limited what I can cram into the available space.
So I finally decided to choose the 53C400.
The design specs are all in the NCR datasheet which is really excellent work, and I even had a card from ebay as a reference.
The 53C400 is a larger chip, but besides a bus transceiver it doesn't need any other ICs.
I designed a revision 3 of my mainboard and built the prototype.
I just moved the 53C400 from the card to my mainboard until I can buy more of them.
I put the transceiver between the ISA slots and removed the secondary SCSI connector which is not necessary persé.
The new prototype with improved tracing to shield the clock signals more got a slightly different impedance (of course).
Because the trace capacitance was raised a few pf, the total load capacitance threw the clock stability of the OSC clock.
It took me some time to find out that this was the cause of some stability problems.
Such a simple thing caused this which was fixed so easily, but first to know it took me some time to realise this
since I never had this experience before with a clock generator.
A very valuable experience once again.
I suppose perhaps I should measure the trace capacitance first before soldering the clock circuits from now on.
This may be a good idea on mainboards to take some bare PCB measurements of impedances compared to ground on fast signals.
That way I can for example adjust the load capacitors on the oscillator a little lower according to the trace capacitance.
I am happy that my REV 3 mainboard works as intended with the existing 53C400 SCSI drivers now.
This SCSI as secondary storage does not require any BIOS which is a bonus.
The driver detects the SCSI without a ROM too.
The mainboard is now again rock solid stable as I saw on the second revision.
So I consider my XT mainboard project finished for now.
I was looking for an IBM discrete chipset 286 AT mainboard project to rebuild but it's hard to find AT mainboards without chipsets.
I would really prefer to have a somewhat newer BIOS as well such as with certain clone boards of the IBM 5170.
I came across an NCR PC-8 model 3279 rev 0XXX mainboard but after buying and repairing it I found that there is a problem with the DMA.
Any DMA operations such as floppy or sound crashes and halts the whole system.
So far I have not found the cause which I suspect may take me quite some time.
My equipment is limited, I only have a simple two channel scope.
Also there may be broken traces because the 4-layer mainboard was soldered in a very warped state onto the slot connectors.
It's warped several millimeters even over a space of about 10cm...
Also it looked like the board suffered some rough treatment.
And there is no schematic either.
Maybe I should go to find a different discrete AT mainboard which at least works properly.
A schematic would also be very handy.
I am not going to design anything that I at least have a working reference system to base it on.
I learned my lesson with the 5380 experience.
I much prefer a working mainboard to base my project on as a reference and for comparison.
Also, I am not particularly liking the strange 5170 circuits made by IBM which were probably used by NCR as well.
The more I study the DMA circuits, the more it looks like a mess which also others agree as I read in some archived info.
It looks like the DMA is only for supporting certain I/O cards.
In fact, the floppy drive doesn't really need a DMA controller since a floppy can be controlled without interrupt and DMA,,
however it was done this way anyway because apparently the DMA controller is better able to adjust to the quirky floppy drive timings than the CPU.
I made a post about my project with the DMA problems on the PC-8 AT mainboard, and still hope to get some attention from IBM AT experts, hopefully.
But it's also possible that my problem is not familiar for other people.
I got the mainboard incomplete so I don't have the original CPU either, I only had a faster and newer one on hand.
Anyway, I like your work on the T128, and great work on equations of the PAL chips too.
I saved your github for future reference.
CPLD sounds good, I also plan to use it in the future, especially for difficult timing which needs to be faster.
I am curious, how is the T128 boot ROM behaving in relation to the XT BIOS and Sergey's HD floppy BIOS?
Do they play nice together or did you see some problem with a HD floppy drive or XT-IDE?
Kind regards,
Rodney
It's nice to see your update.
My compliments on your work!
You are preserving a piece of historical technology.
I just want to say, I see your work and I also feel that it is a valuable effort.
I am also doing my work for preservation of historical designs even though I may have changed them already.
Not many people may understand this point, depending on how they feel about it.
Otherwise many designs will get lost in time never to be found again for sure.
This already happened too much.
I always feel surprised that someone would not feel it's important to preserve these designs, especially the people who originally made them.
I would not want my work to disappear and would always make sure to keep it somewhere in some form at least.
Finally I decided to abandon the idea of using the 5380 on the mainboard.
I mean, if I were determined, I could integrate your schematics into my mainboard,
however it would take up a lot of PCB space which made me decide against it.
On a card it would be fine to use your Trantor schematics of course.
That area of my mainboard is quite limited what I can cram into the available space.
So I finally decided to choose the 53C400.
The design specs are all in the NCR datasheet which is really excellent work, and I even had a card from ebay as a reference.
The 53C400 is a larger chip, but besides a bus transceiver it doesn't need any other ICs.
I designed a revision 3 of my mainboard and built the prototype.
I just moved the 53C400 from the card to my mainboard until I can buy more of them.
I put the transceiver between the ISA slots and removed the secondary SCSI connector which is not necessary persé.
The new prototype with improved tracing to shield the clock signals more got a slightly different impedance (of course).
Because the trace capacitance was raised a few pf, the total load capacitance threw the clock stability of the OSC clock.
It took me some time to find out that this was the cause of some stability problems.
Such a simple thing caused this which was fixed so easily, but first to know it took me some time to realise this
since I never had this experience before with a clock generator.
A very valuable experience once again.
I suppose perhaps I should measure the trace capacitance first before soldering the clock circuits from now on.
This may be a good idea on mainboards to take some bare PCB measurements of impedances compared to ground on fast signals.
That way I can for example adjust the load capacitors on the oscillator a little lower according to the trace capacitance.
I am happy that my REV 3 mainboard works as intended with the existing 53C400 SCSI drivers now.
This SCSI as secondary storage does not require any BIOS which is a bonus.
The driver detects the SCSI without a ROM too.
The mainboard is now again rock solid stable as I saw on the second revision.
So I consider my XT mainboard project finished for now.
I was looking for an IBM discrete chipset 286 AT mainboard project to rebuild but it's hard to find AT mainboards without chipsets.
I would really prefer to have a somewhat newer BIOS as well such as with certain clone boards of the IBM 5170.
I came across an NCR PC-8 model 3279 rev 0XXX mainboard but after buying and repairing it I found that there is a problem with the DMA.
Any DMA operations such as floppy or sound crashes and halts the whole system.
So far I have not found the cause which I suspect may take me quite some time.
My equipment is limited, I only have a simple two channel scope.
Also there may be broken traces because the 4-layer mainboard was soldered in a very warped state onto the slot connectors.
It's warped several millimeters even over a space of about 10cm...
Also it looked like the board suffered some rough treatment.
And there is no schematic either.
Maybe I should go to find a different discrete AT mainboard which at least works properly.
A schematic would also be very handy.
I am not going to design anything that I at least have a working reference system to base it on.
I learned my lesson with the 5380 experience.
I much prefer a working mainboard to base my project on as a reference and for comparison.
Also, I am not particularly liking the strange 5170 circuits made by IBM which were probably used by NCR as well.
The more I study the DMA circuits, the more it looks like a mess which also others agree as I read in some archived info.
It looks like the DMA is only for supporting certain I/O cards.
In fact, the floppy drive doesn't really need a DMA controller since a floppy can be controlled without interrupt and DMA,,
however it was done this way anyway because apparently the DMA controller is better able to adjust to the quirky floppy drive timings than the CPU.
I made a post about my project with the DMA problems on the PC-8 AT mainboard, and still hope to get some attention from IBM AT experts, hopefully.
But it's also possible that my problem is not familiar for other people.
I got the mainboard incomplete so I don't have the original CPU either, I only had a faster and newer one on hand.
Anyway, I like your work on the T128, and great work on equations of the PAL chips too.
I saved your github for future reference.
CPLD sounds good, I also plan to use it in the future, especially for difficult timing which needs to be faster.
I am curious, how is the T128 boot ROM behaving in relation to the XT BIOS and Sergey's HD floppy BIOS?
Do they play nice together or did you see some problem with a HD floppy drive or XT-IDE?
Kind regards,
Rodney
Attachments
Hi everybody, i would like to ask if anyone could dump the GAL on this SUMO SCSI Card. I made a clone of a similar Card here: Github and would like to use the sumo BIOS because there is an ASPI Driver for it.
A simple dump should suffice. I looked at the schematics on Olegs Github page and the Pinout should be:
1,2,3,4,6,7,8,9,11: Input
5,13: don't care
12,14,15,16,17,18,19: Output
Hera a piece of the schematic:
Thanks,
-robert
A simple dump should suffice. I looked at the schematics on Olegs Github page and the Pinout should be:
1,2,3,4,6,7,8,9,11: Input
5,13: don't care
12,14,15,16,17,18,19: Output
Hera a piece of the schematic:
Thanks,
-robert