Another PiStorm Blog

[exxos]

There's a new Github branch of the code now: https://github.com/gotaproblem/pistorm- ... ee/may2024

Cool.

Might not get time this week to do anything again though. A lot going on in and out of Atari world.

[stephen_usher]

I know what you mean. I've put this on the back burner this week as I'm finishing the preparations for the Portables exhibition event in Cambridge next weekend.

[Badwolf]

OK, implemented that change, though 0x1FFD is not correct, I'm using 0xFF00 as anything else fails to go get out of the loop.

The value of l is usually 0xd9xxxx6c or 0xd9xxxx7c. The xxxx values are usually 0x0000 but often 0xffff and sometimes other values such as 0x4001, 0x4081, 0x7fef or 0x5bef.

Hmm, I must be misremembering what gpio[13] returns as it looks like l is 32 bits and shifted right 8 at the end to get the status.

I was assuming I was masking the 16 bits being passed from the verilog.

My mask probably needs to apply to the shifted, truncated result rather than the native 32 bit l, in that case.

So perhaps something more like

Code: Select all

inline
uint16_t ps_read_status_reg () 
{
  static uint32_t l;
  static uint16_t status;

do {

  while ( gpio [13] & 1 );

  gpio [7] = 0x4C; //(REG_STATUS << PIN_A0) | (1 << PIN_RD);

  while ( gpio [13] & 1 );

  l = gpio [13];
  status = ( l >> 8 );

  gpio [10] = TXN_END;
  
}while ( (status & 0x1FFD) != 0 );

  return status;
}

?

But I'd still prefer to use the 'original' status getting code for starters.

BW

[stephen_usher]

The latest emulator code just checks for an invalid status, prints an error message and then ignores the status as a workaround.

[stephen_usher]

Some new firmware and emulator binaries turned up on Friday but due to other commitments I've only had a chance to test them today.

Well, on a positive note I can get to the TOS 1.04 desktop... But the emulation crashes as soon as I double click on a drive icon.

The new firmware doesn't seem to map local ROM images, so it's booting from the on-board ROMs. I also had to decrease the GPIO clock even further down to 68MHz. Any more or less than that made it totally unstable.

It feels to me that the first thing that needs sorting out is the communication between the CPLD and the Raspberry Pi. Unless this is rock solid you're trying to fight on multiple fronts and the project won't get anywhere.

I also wonder if the CPLD part fitted by the board manufacturer is genuine and not a rebadged slower part.

[stephen_usher]

Spent some more time with the PiStorm.

Back to relatively stock firmware and the May edition of the software.

I still can't get the GPIO clock above 70MHz stably, and even with that there's the odd glitch.

Seeing as I was having issues with WiFi wit the large CPU heatsink fitted I cut it down my half so it no-longer overhangs the WiFi module. That fixed the networking issue but also improved slightly the attainable maximum GPIO clock. However, I noted crashes of the virtual CPU seemed to correlate with bursts of WiFi traffic to/from the Pi. Putting a little aluminium foil over the GPIO connector between it and the WiFi module increased reliability a bit suggesting that RF from the WiFi module is having an effect upon the GPIO pins, possibly a harmonic of the 2.4GHz carrier or just induction.

I also re-implemented the test for a valid status register return into gpio/ps_protocol.c. Gone are the 'bad status' messages form the main emulation and the system is more stable. The TOS 1.04 now doesn't crash immediately if you click (once) upon a desktop icon but instead just fails to recognise further mouse (or ctrl-Ins) presses or mouse-over on the menus. GEM is probably triggering one of the CPU stati that the PiStorm isn't currently emulating.

[Steve]

That's very odd (the WiFi stuff) I haven't noticed anything like this. My WiFi is on & sharing the Atari hard disk over samba. So I can write to my Atari in real time and access the files inside the machine straight away, not experienced any crash when accessing the WiFi before.

[stephen_usher]

The main maintainer says that he has the PiStorm stable on his STe as well with a clock at around 90MHz. With the heatsink out of the way I can get the memory tests working at that speed but not the emulation, far too many random memory read errors.

I've no idea why the Exxos sourced PiStorm would be more sensitive than anyone else's. Then again another person in Germany on the Discord seems to be having similar issues with stability.

[stephen_usher]

I've been doing some experimentation today and here are the results:

Set-up:
Pi4 running at 1.8GHz. Exxos PiStorm. STFM with my relocator/CPU switcher/ROM switcher and decode.
EmuTOS 1.0 256K.

PiStorm configuration:
GPIO clock: 68MHz
Emulation: 68000/ST
Mapped ROMs/RAM: None.

Started with loopcycles at 1 and doubled each test.

Test software: YAART and then Fronbench if YAART stable.

Loopcount 1 - 16: Random corruption when running YAART. EmuTOS catching errors and returning to desktop.
Loopcount 32: System generally stable. Can run YAART without issue. Frontbench loads sometimes other times gives corruption. YAART errors out if Pi asked to do anything other in addition to the emulation.
Loopcount 64: As 32 but Frontbench loads every time and runs stably. Less sensitive to system usage.

By a loopcount of 256 the system is rock solid.

TOS 1.04 will boot to the desktop but as soon as any icon is clicked upon (once) the system locks or resets with two bombs. If I reject more CPU stati from the PiStorm then I can get TOS to stay alive but then no clicks are registered by GEM. Seems like the highlighting of an icon causes a CPU state that the PiStorm CPLD isn't yet emulating, or the CPU emulator doesn't know how to process.

On my system any GPIO clock slower than 68MHz and faster then 70MHz causes the system to be unstable. Bursts of WiFi traffic can also cause instability. Shielding the GPIO connector from the WiFi module can limit this slightly.

[stephen_usher]

I've been doing some more testing for cryptodad.

Tonight I was testing his clock generator code for the Raspberry Pi.

Initially I tried with the Hantek 'scope but knew I was pushing it as the 'scope is only rated for 100MHz and the GPIO clock is above that.

With his new test software I hooked up the Hantek and ran the test. I couldn't get a large signal but the 'scope said that it was 129.601 MHz. I didn't trust that figure though. So, I decided to bring out the Tektronix 'scope and hope that it would boot properly tonight.

After setting up I pressed the power button and after about two minutes it said that the self-test had passed. Phew!

IMG_3734.jpeg

Hooked up the probe, hit the "auto setting" button and...

IMG_3733.jpeg

Yep, a nice signal and precisely the same frequency measured as on the Hantek. So, the Hantek can be trusted.

Running the test code showed that when the Pi was accessing the PiStorm it created quite a bit of jitter on the clock, over 10%, which is rather a lot! And it's noisy too.

IMG_3736.jpeg

Still, I don't think that is likely to be the cause of the stability issues, but it is concerning how much possible cross talk is going on.

Testing his original code, if run without the --clock option his program thinks that it's generating a 125MHz clock but in fact it's 187MHz, way outside the range Broadcom state is permissible to work reliably. With the "--clock 80" setting the clock signal is precisely 125MHz.