68030 bootstrapping issue

[Badwolf]

Slow progress yesterday. I spent a couple of hours reading TF's verilog & thoroughly confusing myself. :lol: Well above my level. Need to git gud.

Have Youtube playing archived livestreams in the background whilst I'm working. TF's fiddling with the Akiko comes on. Half way through he literally does a Dave Jones style explanation of the clock generation logic I was scratching my head over last night.

That's timing for you. Cheers, Stephen!

NB: as I understood it, this technique needs knowledge of the ratio of the 'accelerated' clock to the 'system' clock to know how many samples to delay and invert by. Since the Falcon's clock frequency isn't fixed, I'm not sure the same method could be directly applied but perhaps some kind of running average could be kept.

BW.

[terriblefire]

If the falcon's clock frequency isnt fixed i'd just remove that clock buffer and try it like that.

[Badwolf]

Quick post-weekend update:-

The instruction fetch messages were indeed linked to the VBL coming unmasked and AVEC not being properly simulated.

I mentioned the Falcon's expansion port is neither Arthur nor Martha when it comes to 68030 vs 68000 lines and further more they completely omitted either AVEC (in 030 lingo) and VPA (in 68000). Both are available on the mainboard, but none pass through. Fortunately only two interrupts require an autovector, HBL and VBL, and they have unique interrupt IDs (2 and 4). I couldn't figure out why my AVEC emulation logic wasn't working.

Well, it turns out Murphy'll get you. IPL0, the low bit of the interrupt priority indicator lines, which passes straight through from the expansion port to the 030 and is tapped off to the CPLD for the purposes of identifying an interrupt 2 or 4, wasn't making it to the CPLD. I suspect the via that taps the line isn't doing its job. Anyway, long and the short of it is that the interrupt levels I thought I was seeing weren't correct, so AVEC was never firing, so errors on the screen.

During the interrupt cycle the 030 puts the (inverted) IPL onto A3:1 so I switched to using those instead and, ta-da:

blue.jpg

There's still a warning on the initialisation screen, which is a strange one. Writing to ROM from the expansion slot doesn't produce a bus error.

buserr_still.jpg

This may be a problem down the line but I don't sniff enough address lines to detect a ROM write and generate my own BERR, so can't do much about it in this revision, though.

All the tests that don't require DMA seem to run fine, which is excellent and a huge leap forward. The blitter and floppy tests fail very rapidly with an exception, though. My first suspect is I think my bus arb logic is releasing the external 030's hold on the bus whilst a bus cycle is in progress, although there are some other oddities to do with me handing the bus back to the onboard 030 for reallocation.

busarb_oopsie.png

I happened to be working on this whilst Stephen went live on his H4/536 discussion last night and he mentioned none of his boards have any kind of busarb state machine, so it could be I've just overdone the thinking on this, but I can't see how I can let either processor perform bus arb natively unless I can think of someway to suppress the onboard CPU without interfering with the global BGK line.

Anyway, I've had my little dopamine boost and can now move on to a different problem, so happy days. Thanks for the help so far, guys.

BW.

[Badwolf]

I've spent the last few days thinking about Stephen's comments regarding the state machine (and having no need for it). I tried simplifying the process and inspecting the 330 and 534 verilog, but I get the impression the CD32 (which is, I think, the only published machine so far where the TF board doesn't replace the onboard processor) has independent lines to the CPU and rest of the system.

Long and the short of it is, I couldn't get a simpler system to work, so went the other way: I extended my state machine to have extra steps to insulate pins going from output to input and vice versa before trying to do logic on them and made some progress.

The blitter test on the diag cart now passes, but floppy access is still a no-go. It looks like commands are being issued (the drive clicks and whirrs -- well, the gotek beeper equivalent), but errors abound. I need to read up on how the FDC interfaces with the system next, I think.

The really significant step, from my point of view, is that booting vanilla TOS now gets to a display! Ok, the display is solid red then, about a minute later, goes solid white, but the keyboard beeper is working. CTRL-ALT-DEL resets the machine and, pressing CTRL-A (desktop shortcut to open drive A in a window) causes disc activity!

This seems to me that I might be reaching the desktop but, for some reason, the video isn't being properly initialised. I suspect the delay in getting to white screen might be related to the floppy clearly not working (the system does finally hang after I try to open A: via that shortcut), but this is as much progress I've had for some weeks.

Here's a video of the process described above.

https://www.youtube.com/embed/QzQCNFcO_n8

Has anyone got any insight into what I might be seeing here or what I might still have goofed on the floppy front?

Thanks all,

BW.

[Badwolf]

Quick update as I've not had chance to work on this for a couple of weeks & I appreciate the help offered on here.

I'm actually pretty confident of the bus arbitration. At 8MHz the worst case I've sampled for relinquishing the bus to another master is 0.6us. This is comfortably within the 1us limit Atari advised. Also I can foment what I presume is the same error when doing the disc change detect test in the diag cart, which doesn't do any bus arb at all.

Ergo, something else is afoot.

I've almost reached the limit of what I can do with the tools at my disposal. So some new hardware is needed.

I bit the bullet and have an TL866 on order (although RS introducing a £5 delivery fee to get the OTP PLCC44 EPROMS is a bastard - Grr) so I'll be able to burn Stephen's DiagROM port and I thought I might have a go with EmuTOS to see if it prints any useful diagnostics.

I've had two failed attempts at a rewritable cartridge ROM, so I've designed another with breakouts to let me breadboard it if need be. That should help avoid the OTP nature of the Falcon's TOS package selection and let me write my own ROM code if push comes to shove.

I've also started work on the next revision of the board which will take a different approach to breaking out lines for testing & add some more address lines to the CPLD, at the expense of those I don't think I need now. That'll let me emulate the missing ROM write bus error on the Falcon's expansion port & potentially allow a fully 512k of directly pluggable EEPROM or flash.

I think I can say the 68030 is now well and truly bootstrapped so I'll probably start a new thread documenting any further development & the next revision board in case someone else tries to revisit this underdocumented part of Atari's architecture in the future.

Cheers,

BW.

[Badwolf]

Slowly, slowly...

IMG_3817.jpeg

A few things to sort out yet. AltRAM (fast) hasn't yet been implemented on this board. I may need to badger some people with a few problems I had with that on the last board (I could 'peek and poke' with my own code, if you like, but when I registered it with the OS it behaved oddly and crashed).

If I enable PMMU in EmuTOS, I get some fantastic boot crashes. Scrolling nonsense up the screen. Quite dramatic.

Also AES 4.1 and TOS aren't happy bunnies yet (see AES4.1 below). Any thoughts on that appreciated.

Biggest steps forward for months, and I'm thoroughly delighted!

BW.

IMG_3819.jpeg