Email or username:

Password:

Forgot your password?
Top-level
Tube🍂Time

the BIOS runs faster than the DIFDIAG utility, and so it seems like it is hitting a timing problem that i didn't hit before.

my drive code seems to randomly hang up and not respond correctly.

76 comments
Tube🍂Time replied to Tube🍂Time

it's occasionally getting a spurious end-of-interrupt command which is really odd and points to an issue with the mailboxes (again, sigh).

but it's SO DARN CLOSE. it's transferring sectors from the IML region in the disk image.

Daniel Schwarz :toad: replied to Tube🍂Time

@tubetime What’s the end goal here, boot the laptop using a SD card that’s emulating a Micro Channel hard drive interface, via Teensy?

Daniel Schwarz :toad: replied to Tube🍂Time

@tubetime I know it’s not the point of your project, but didn’t this laptop have PCMCIA? Would one of these work as a boot drive?

Digigear SD SDHC SDXC to PCMCIA PC Card, Adapter Supports, ATA Flash Memory a.co/d/agF7LO9

Tube🍂Time replied to Tube🍂Time

figured out one problem. the disk boot routines slam the drive with an ATN and the first command word in 5.5us. the Teensy code takes too long to see the ATN and clears the command register full flag, which drops the first word. oops.

Tube🍂Time replied to Tube🍂Time

so it *almost* boots now. in fact it successfully loads the IML sectors from the hidden partition on the drive, and no longer throws an I999... error code!

Tube🍂Time replied to Tube🍂Time

my drive doesn't implement this weird feature called pseudo RBAs--it's a way to artificially limit the maximum possible block address, presumably so they can hide the partition data.

i suspect the BIOS checks this, so i'll have to implement it. ugh. that means i need to figure out this incomprehensible diagram.

Tube🍂Time replied to Tube🍂Time

holy crap it's booting I can't believe it sdfadfsdfsdfsffasdf

Tube🍂Time replied to Tube🍂Time

well, it's working well enough to run qbasic. right now the drive is read-only.

Marsh Ray replied to Tube🍂Time

@tubetime “It’s working well enough to run QBASIC”

Love it 😂

Tube🍂Time replied to Tube🍂Time

i think i need to dig into the 01290200 cache error that has been coming up. i'm concerned that an issue with my DBA-ESDI card has caused it, but i'm not sure.

Tube🍂Time replied to Tube🍂Time

looks like the cache is inside the CPU. i can't find any cache chips on the motherboard.

Tube🍂Time replied to Tube🍂Time

see? no cache or memory chips. the larger devices are probably semicustom gate array parts that IBM was fond of using. doubt they contain any cache memory.

Fritz Adalis replied to Tube🍂Time

@tubetime
@kenshirriff just posted about these CPUs. They have most of the support circuitry in the cpu itself.

Tube🍂Time replied to Tube🍂Time

looks like the error is generated by an NMI that gets tripped when the cache is being set up. could be a number of causes but in general it is an issue with the internal CPU cache.

Tube🍂Time replied to Tube🍂Time

could also be this test of the DMA controller which is also included in the same set of tests and triggers the same error code, for some reason.

Tube🍂Time replied to Tube🍂Time

hmm, the error still comes up. so i just tried what i *should have tried* at the start -- the 700 series diagnostic disk.

Tube🍂Time replied to Tube🍂Time

when the diagnostic detects the cache error, it asks if you have replaced the CPU card. i *lied to it* and said that I had, so when it asked if i wanted to keep the cache disabled, i said "N".

Tube🍂Time replied to Tube🍂Time

aaaand that fixed it! we're now booting to DOS off my DBA-ESDI disk replacement.

Tube🍂Time replied to Tube🍂Time

so here's what i think happened:
1. my early version of the FPGA code had a typo that caused the BURST# line to be held low
2. this caused the DMA controller to get stuck and time out during the cache test, presumably a very early CPU test that checks for cache coherency.
3. this error is *sticky* and gets written to some nonvolatile memory (perhaps not CMOS since i couldn't clear it by pulling the battery.)

Tube🍂Time replied to Tube🍂Time

this is all very good because i know the root cause and it's not something terrible like data bus contention, and it's thankfully not permanent damage.

Tube🍂Time replied to Tube🍂Time

it boots windows 3.1 now. it was trying to run a weird hdd power saving mode command I hadn't implemented. it also complains about the swap file because the filesystem is read only still.

Tube🍂Time replied to Tube🍂Time

so about that write issue: it's an off-by-two error somewhere. two bytes being a single 16-bit word, so it's really an off-by-one error.

Chuck replied to Tube🍂Time

@tubetime of course it is. 🙂 Thinking it was an off by two error was off by one. 😂

Tube🍂Time replied to Tube🍂Time

figured it out and fixed it. i forget to set the "transfer request" flag to kick off DMA.

in another routine, it sees that this flag is clear and assumes that a word has already been read using DMA, so it reads a crap value and then sets the transfer request flag again to start the next DMA transfer. that "crap value" pushes the valid data forward by one word.

Tube🍂Time replied to Tube🍂Time

on to the next issues: randomly the ATN register mailbox flag gets set but the data in it is stale. also, the status interface register will randomly get read from by the host.

I think these are two facets of the same problem: the mailbox flags sometimes respond when you access a register that they are not supposed to be monitoring!

Tube🍂Time replied to Tube🍂Time

the mystery deepens. according to the logic analyzer, temp_atn_set never goes high. reg_atn_set (for crossing clock domains) is always 000. flag_atn is only set to 1 on this single line of code!

and yet, somehow, it magically flips to a 1.

Tube🍂Time replied to Tube🍂Time

looking at the generated logic, i see no explanation either. temp_atn_set (aka sd_cmd, my test point) never goes high. no glitches, no nothing. to set the flop, EN must be high and R must be low, and a clock edge must occur.

Tube🍂Time replied to Tube🍂Time

there's a glitch! that's why I missed it before, it's only 2ns. this is the signal from the MCA bus clock domain, and it's getting picked up in my other clock domain's edge detector.

Tube🍂Time replied to Tube🍂Time

and i believe this is the cause. this line right here. each signal, la_*, is an output from a flip flop latched by the micro channel bus cmd line. however, this line of code creates some combinational logic--there's a timing hazard here...

Tube🍂Time replied to Tube🍂Time

the problem? the line (la_addr == REG_ATN) creates a bunch of gates that are slightly slower than the simple AND gates in the previous part of the line.

so la_mca_op=1, ~la_s0_w_l=1, and (la_addr == REG_ATN) *is also a 1 for a very short time!!!* this is because the previous value of la_addr WAS a REG_ATN.

what i need to do is take that entire wire and turn it into a latch (a reg) and clock it on cmd.

Tube🍂Time replied to Tube🍂Time

so here's the solution: all the signals in the MCA bus domain go to a latch clocked in that domain (the first "always" block).

then *without any combinational logic* the output of that latch goes *directly* to another latch (the second "always" block) located in the main clock domain.

(i have another flip flop in main clock domain just for detecting the edge)

Tube🍂Time replied to Tube🍂Time

next step is to optimize the interface speed. right now it takes 25us to read a sector from the SD card but ~5 milliseconds (ouch) to DMA it to the PC!

it's mostly an issue with the Teensy-to-FPGA interface, which is async and simple: 4 address lines, 16 data lines, a read control line, and a write control line. everything else is done as a register in the 4-bit address space. flag register for status and mailbox sync bits.

Tube🍂Time replied to Tube🍂Time

why is it 5ms per sector for DMA? well, it's about 20us per word. most of that time is wasted by the slow interface between the Teensy and the FPGA. I really should fix that.

Tube🍂Time replied to Tube🍂Time

got rid of some delays and now we're down to 6us per word. but there are some unexpected wide gaps in between transfers between the FPGA and the Teensy.

Tube🍂Time replied to Tube🍂Time

ahh that must be the issue, when i change from a read to a write, i have to set the port direction for 16 IO pins. pinMode is uhh not quick, so let's try writing to the port direction register directly.

Tube🍂Time replied to Tube🍂Time

that's better, it's 2us per word now.

Tube🍂Time replied to Tube🍂Time

so how does this compare with the real drive? it transfers a word in about 1.6us (compared to 2us for mine), so it is slightly faster for sustained data transfer with data that fits in the internal buffer. however, seek times (in the ms range) more or less cancel this out.

Tube🍂Time replied to Tube🍂Time

here's a DMA cycle for the real hard drive. it's using the bus more efficiently, requesting a new transfer as soon as the transfer completes. my design waits for the full DMA cycle to end before requesting a new one.

dumb future replied to Tube🍂Time

@tubetime This was really enjoyable to follow along with! Congrats on the progress

Vlad Vukicevic replied to Tube🍂Time

@tubetime "No command can not access" so.. uh.. commands can access? 🤯

Tube🍂Time replied to Vlad

@vvuk the document is full of typos and errors.

Vlad Vukicevic replied to Tube🍂Time

@tubetime Your project is an ESDI drive emulator, right? (specific drive type, but ESDI interface) Would it work in another computer that had an ESDI controller and understood the IBM drive?

(I assume so, but then you mentioned microchannel which confused me -- I'm assuming the "creaky old IBM laptop" interface is ESDI?)

Alan Martello replied to Tube🍂Time

@tubetime Your recent posts make me believe you’re a time traveller - perhaps the great-great-grandson of an IBM engineer who as a child found an old notebook complaining about this problem your grandpa just couldn’t solve and that he was fired for and altered the arc of his life. You studied your whole life as an engineer for this moment to come back to today when the hardware was still available, fix the problem, then go back and help your grandpa. Let us know how it turns out.

Tube🍂Time replied to Alan

@amart not too far off! my grandfather worked there. i once reverse engineered a prototype floppy drive he worked on, and got it working again. twitter.com/TubeTimeUS/status/

Go Up