Raspberry Pi Pico disk controller for Intel 80188

[@ModSlash]

Was looking forward for a new video from you for a good while now :) Welcome back :)

[@SladorSoft]

Oh, thank you @ModSlash. Yes, I had a break, but from now on, I'll try to reserve as much time as I can to make videos more often. I have this problem, where I have more ideas than the time to realise them... ;-)

[@brutester]

Interesting project, but I have a question - why not use a CompactFlash to IDE adapter? This is what we've been using as a server boot drive for a decade in early 2000s

[@sjococo]

CF is indeed a 16 bit IDE card and can be directly connected to a 16 bit ISA bus with 2 74245 buffers. A 8088 and 80188 have a 8 bit ISA bus, so a XT-IDE ISA card is a solution for a CF card that exists for years as the 8 bit IDE hard disks like Seagate ST351X are very rare. A 80186 and up have a 16 bit ISA bus and can use a CF card directly. CF has a parallel interface and SD a serial interface and there is where the fun starts...

[@freddyvretrozone2849]

This will take the same amount of time to adapt an xtide to this than doing on pico because xtide talk to isa and here it is direct cpu access. This board is not pc compatible so it require à huge work to rewrite the xtide bios. See how simple it is to code at the 80188 side with just some registers vs ide.

[@sjococo]

@@freddyvretrozone2849 a 8088 XT does not have hard disk support in it's main bios like a 80286 AT and up have. How different is the connection to this CPU than the connection via the ISA bus on a PC XT? I have to dig deep in my memory concerning DMA and Interrupt controllers...

[@SladorSoft]

Thanks a lot @sjococo! Yes, what you said was exactly my point for not using CF. I added this Pico there not only for the SD card access, but also for keyboard, UART and maybe other peripherals later. It's so much simpler doing it with this Pico board rather than adding support for long forgotten CF cards where I'd need to add something in-between to use it on a 8-bit bus. And also, @sjococo mentioned the most important reason in their last paragraph ;-) That's where the fun starts :-)

[@SladorSoft]

Thanks @freddyvretrozone2849. Since the beginning, I emphasised that I'm not trying to build a PC compatible, but I do this only for fun and to have a chance to talk about this old technology. Also, the whole point is to write a BIOS myself, not to use anything out there. It's a project I started for fun, that's it :-)

[@Kitsok]

Good project! Do you think about DMA implementation? It would drastically increase the performance.

[@SladorSoft]

You are perfectly right @Kitsok! This was just a first attempt to test the idea. Surely, the next step is to implement it properly using DMA. And it's going to be a good excuse to look more closely at the timings in both cases using a logic analyser.

[@matgaw123]

Im Wondering how many times faster the pico is compered to 80188 Any way cool project Very interesting to watch

[@SladorSoft]

Thank you! Yes, I was wondering about it as well... It's hard to estimate, but... are you thinking what I'm thinking? ;-) Maybe at some point in the future, I'll try to emulate 80188 on Pico?

[@matgaw123]

@@SladorSoft that would be awesome tbh but also hard

[@matgaw123]

@@SladorSoft CoreMark 67.181 CoreMark/MHz 1.0179 Inter 486 And pico CoreMark about 260 CoreMark/MHz about 2 Pico 2 Core mark about 600 Core mark/MHz about 4 RISC cores also about 4 Pico 4x st 8xmt Pico2 10x st 20x Mt St-single thread Mt-Multi tread

[@marcrobach7376]

So, you read the 512 bytes of the sector from the DATA register using a loop. What I don't understand is how this is synchronized. Is it possible that you might accidentally read the same byte twice because the next byte has not yet been written to the DATA register?

[@rasz]

init.asm line 127 checks DISK_CTRL_STATUS_BUSY until data is ready. The way PC disk controllers work they receive a command to read one or more sectors and will only give signal when they have at least one full 512-byte sector ready, either with interrupt or by changing status.

[@SladorSoft]

I'm sorry @marcrobach7376, because it looks like I didn't explain this well enough and thanks @rasz for clearing this up. So the Pico first reads the whole sector to its own memory, then clears up the "busy" flag, which lets the Intel CPU to read this buffer byte by byte. The Pico has it's own pointer to the next byte to be read in this buffer and each access from the main CPU increases this pointer. Maybe I should have showed the most important parts of the Pico code in the video - sorry for that confusion.