• Please review our updated Terms and Rules here

1000SL: "Err I/O of port 378h", not booting

I have no idea how to do that. Can I get the binary pattern by checking voltage on pins to ground? Is it that simple?

If that's the case, PD0 to PD7 are alternating 10101010, which google says is AA in binary?

"The value of HEX AA in decimal is 170. The value of HEX AA in binary is 10101010"
 
Last edited:
I also see some of the same code in the bios file I've dumped. The 16kb file has BA 78 03 at offset 7B3, followed by what looks to be some of same code afterwards. B0AA doesn't appear until much farther down tho, offset 25A7.

maybe I did screw up the rom dump somehow...
 
Your ROM contains similar code (at offset $47E0 in the F800 file) except that it only writes the $55, which matches what you measured at the port if bit 0 was at 5V, bit 1 was at GND, bit 2 at 5V, and so on. So the data is being written correctly, but evidently not being read back. Can't say why that is. Maybe someone else can weigh in...

If you have the capability to program a modified EPROM and swap it in, you could try bypassing this check and see if the PC boots without any other problems. Changing the byte at $47E8 from $74 to $EB should bypass it.
 
Your ROM contains similar code (at offset $47E0 in the F800 file) except that it only writes the $55, which matches what you measured at the port if bit 0 was at 5V, bit 1 was at GND, bit 2 at 5V, and so on. So the data is being written correctly, but evidently not being read back. Can't say why that is. Maybe someone else can weigh in...

If you have the capability to program a modified EPROM and swap it in, you could try bypassing this check and see if the PC boots without any other problems. Changing the byte at $47E8 from $74 to $EB should bypass it.

I can definitely write a new rom, I was already contemplating trying to bypass this error in just such a way.

Something like the 27SF020 eeprom should be compatible, right? Pinout looks the same. I'd rather not have to dig out my UV eraser and tinker with eproms...
 
Last edited:
I used a gotek and got the debug.com rom dump.

Rom 1 looks like msdos stuff, the actual bios must be somewhere in the second file (MYF800.BIN)

View attachment 66593

Although it might not be as needed any more, I'll still spend an hour disassembling and commenting this, just for posterity.

Chuck: Had no idea the copyright string in both ROMs was intentional. It definitely looked like a dumping or merging bug; thanks for the note.
 
The F800 file is rom version 1.04.02; the original I posted is 1.04.00. It might be interesting to see what the differences are.

I also have a totally dead SL motherboard with some proprietary Hitachi roms I'd like to dump...
 
Your ROM contains similar code (at offset $47E0 in the F800 file) except that it only writes the $55, which matches what you measured at the port if bit 0 was at 5V, bit 1 was at GND, bit 2 at 5V, and so on. So the data is being written correctly, but evidently not being read back. Can't say why that is. Maybe someone else can weigh in...

The full code block is:

Code:
seg000:C7DD                LPT_test:                               ; CODE XREF: seg000:C799j
seg000:C7DD                                                        ; seg000:C79Ej
seg000:C7DD BA 78 03                       mov     dx, 378h
seg000:C7E0 B0 55                          mov     al, 1010101b
seg000:C7E2 EE                             out     dx, al          ; output test pattern to LPT port
seg000:C7E3 EB 00                          jmp     short $+2       ; wait a bus cycle
seg000:C7E5 EC                             in      al, dx          ; read test pattern back from LPT
seg000:C7E6 3C 55                          cmp     al, 1010101b    ; does it match?
seg000:C7E8 74 20                          jz      short setupDMA  ; if it matches, continue with POST
seg000:C7EA BE F5 C7                       mov     si, offset aErrIOOfPort378 ; "Err I/O of port 378h"
seg000:C7ED BF 80 07                       mov     di, 1920        ; last row of screen
seg000:C7F0 E8 5A 04                       call    prtNulTermStr
seg000:C7F3
seg000:C7F3                hangloop:                               ; CODE XREF: seg000:hangloopj
seg000:C7F3 EB FE                          jmp     short hangloop

So something is off with the printer port, but if you don't care, I concur that patching the jz to jmp will let you continue:

If you have the capability to program a modified EPROM and swap it in, you could try bypassing this check and see if the PC boots without any other problems. Changing the byte at $47E8 from $74 to $EB should bypass it.

BTW, here's a first pass at the system BIOS disassembly/listing: ftp://ftp.oldskool.org/pub/drivers/Tandy/1000 SL/BIOS ROM 1.04.02/Tandy 1000 SL System BIOS.lst
 
Last edited:
The Tandy FAQ http://www.oldskool.org/guides/tvdog/1kfaq.html#II.C.1 mentions a BIOS modification needed when installing an HDD on early machines (find the part "BIOS programs the DMA controller for extended write cycles") but does not mention having to correct a checksum, so I'm guessing that won't be an issue. I only bring this up regarding the question of a BIOS checksum.

To modify the byte at $47E8 then only affects the "even" ROM. Of course you'll have to recalculate the address to locate the correct spot on the ROM. I'm not sure what size chips you have or how exactly they are mapped in the address space. But matching the ROM contents up with the software dump should be enough to locate the byte.
 
Last edited:
Finally got my 27020 chips in the mail, they were lost for almost a month thanks to USPS...

I burned copies of original ROMs and system boots and displays Err IO 278 message, so I know the chips will work.

I changed the value from 74 to EB in the U3 rom at position 3 E3DF and re-flashed and re-installed the roms and only get a blank screen, same behaviour if no rom is installed at all.

Possibly there's a checksum byte that needs to be modified, OR it's skipping the printer failure and encountering another untrapped failure farther in.
 
Well it's not a checksum issue, I modified rom to say ERR IO of part 378h instead of "port" and it displayed the altered message, which would have tripped checksum if that were being checked.

Obviously something is wrong beyond the parallel port.

Odd thing is that I've swapped the socketed PSSJ/etc. chips with known-good ones and nothing changed...
 
For me, 86box gave this very same error. Tandy 1000 SL/2 emulation gives this error code, so maybe the ROM set of 86box is not complete? i dled it from github, the most recent one. Only google hit for the search "Err I/O of port 378h" is this forum...
 
Is there a solution for this problem? I also have a Tandy 1000SL with the same problem. First this Tandy had a memory error, after replacing the memory ICs, I got the 378h error
 
Is there a solution for this problem? I also have a Tandy 1000SL with the same problem. First this Tandy had a memory error, after replacing the memory ICs, I got the 378h error
And like i said, i had got the same error message.. from an emulator! Namely, 86box. Maybe they had dumped a faulty ROM for their ROM set that is downloadable.
 
Does 86box account for the 1K EEPROM, similar to PCEM? Additionally, and from the hardware side of things, could someone with the issue try reseating the EEPROM IC at U17 (beneath the power-supply) and see if the error persists?
 
Already done it.
I would like to compare the data with a working 1000SL. It is a 93c46.
With and without EEPROM the machine gives the same error.
So I think we have to look there.
 
I tested the EEProm and it is broken.
So now I am looking for a copy of the data.
 
Back
Top