PiStorm Chat

[alexh]

Probably nothing but if you google "68000" and "2704" you get two references (1 2). Both have SR = 2704

[Badwolf]

Probably nothing but if you google "68000" and "2704" you get two references (1 2). Both have SR = 2704

Cool. Makes sense with it being a stack push for an exception then, doesn't it?

I'd guess it's the EmuTOS CPU detection code running.

I was thinking hardware fault last night (latch toggling all the time or something like that), but the more I think about it, and the solid reliability of the ROM (and, incidentally register) reads makes me think it's simply latch (or read-back from the flip flop) timing.

Here's the pertinent part of the CPLD logic:- https://github.com/captain-amygdala/pis ... orm.v#L242

Which on the face of it looks fine -- it latches in S4, having moved on from S3 only when DTACK is asserted. But I don't like the look of that PI_TXN_IN_PROGRESS_delay business. I might nix that.

BW

[Badwolf]

So it turns out the PiStorm logic was latching far too early in the bus cycle. This worked for ROM as I have a nice fast ROM that's driven early, but RAM follows the 68k datasheet more accurately and doesn't even drive the bus until some time after DTACK is asserted. One of those things where it's been tweaked down and down for speed, but only on one system.

The PiStorm was latching on DTACK received and therefore geetting mostly what was on the bus from the previous cycle. Latching in S6 and terminating the cycle in S7 sorted out the memory problems. There was then an issue with reset (the virtual CPU issuing a reset instruction also reset the CPU...). But then we get:





Now this is stuck in (I presume) an interrupt and doesn't progress pass the splash screen, but progress is being made.

I'm going to try to work on bus error next (tricky) so I can employ the diagnostic cart to help with the interrupt business. I *think* PiStorm ATM only handles autovectored interrupts and am pretty sure it doesn't issue an IACK properly, so plenty to work on there.

BW

[agranlund]

This is awesome progress!

:bravo:

[Steve]

I'm not exaggerating when I say this could be the most important and powerful piece of hardware on the atari platform, if you get it working :) Once the CPU side is working, we then suddenly have the ability to add all of these things: HDMI Nova-like graphics output in high res, high colour / USB drive mounting / wifi/ethernet and lots lots more possibilities .....

[Badwolf]

IMG_5643.jpeg

Well that's a nice sight.

Bus error still crashes the emulator ATM (not wrapped my head around Musashi enough to know how to assert it), I've not written the bus arb yet (so no disc drives), it's slower than a wet weekend in the Western Isles (no attempt at optimisation) and it's crashing every few minutes, but progress!

BW

[alexh]

Congratulations. What did you need to do to get this far?

[Badwolf]

Congratulations. What did you need to do to get this far?

Crikey. Quite a few things. Here's a couple I can think of off the top of my head:-

• The reset instruction is a problem. It's not really working properly ATM. I tried changing the way the CPLD works but ended up commenting out the CPU re-initialisation in the emulator. You can't reset with the hardware button ATM.
• Non-autovectored interrupt support. This is a hack at the moment. I added an interrupt acknowledge cycle but I'm just autovectoring IRQ 2 and 4. I'm not detecting VPA.
• Slowed down the bus cycle. PiStorm had been (empirically) adjusted to latch on S4(!) as that works on Amiga. Changed to S6 for now.
• Added FCx lines to each bus cycle and enabled in the CPLD and emulator.
• Am checking every bus cycle for a bus error. This is slow.
• Tried to get bus error to work in emulator, but ATM this is using a hacked EmuTOS without bus errors. Biggest problem still to solve. Segfaults occasionally.
• Bus arbitration added to the CPLD to get the floppy to work

Very unstable ATM and obviously relies on that special EmuTOS. RAM access is very slow because of all those de-optimisations I've employed.

BUT disc access is now working:-

IMG_5646.jpeg

CPU speed is OK. ROM is mapped from the Pi so nice and quick. RAM? There's your problem.

BW

[exxos]

Some good progress in any case :thumbup: Half speed RAM is like hello world in CPU land :)

[mgi]

Impressive progress!!!!